Functional and security model for SEAL

What's the functional and security model for SEAL?

From this I get that it

allows additions and multiplications to be performed on encrypted integers or real.

But what are the limitation, like range, precision, on inputs and outputs? What operations can be performed? Is there some limitation beyond range/precision?

What is the security model an application designer using SEAL as a black box should assume?

I'm especially puzzled by the following stated limitation (source):

decryptions of Microsoft SEAL ciphertexts should be treated as private information only available to the secret key owner, as sharing decryptions of ciphertexts may in some cases lead to leaking the secret key.

Does that mean an application using SEAL to e.g. compute the mean and variance on an encrypted data set can't publish the (decrypted) results? At least, the first (say) 4 decimal digits of mean and 2 first of variance must be OK to publish, right? If so, what's the limit of safe, or/and is there some built-in API to sanitize output so that it can safely be revealed?

decryptions of Microsoft SEAL ciphertexts should be treated as private information only available to the secret key owner, as sharing decryptions of ciphertexts may in some cases lead to leaking the secret key.

This was put in place as a response to the Li Micciancio attack on CKKS. The model Li Micciancio [LM] work in is traditional IND-CPA security augmented with a decryption oracle. This decryption oracle only decrypts if the "ideal" result on the left and right worlds match, so for correct FHE schemes (where the ideal computation is the computation which actually occurs) the notion is equivalent to IND-CPA security (any adversary could trivially simulate this oracle).

For schemes that may be incorrect, the equivalence no longer holds, and LM can break this augmented notion of security (and even extract the secret key). Several libraries have incorporated countermeasures as a result, you can read a summary here. I quote from this document:

SEAL. Currently, a modification for IND-CPA+ security on algorithms or API does not appear in SEAL [18]. Instead, they noted in SECURITY.md that the decryption results of SEAL ciphertexts should be treated as private information only available to the secret key owner.

So the answer to:

Does that mean an application using SEAL to e.g. compute the mean and variance on an encrypted data set can't publish the (decrypted) results? At least, the first (say) 4 decimal digits of mean and 2 first of variance must be OK to publish, right?

is "it depends". As SEAL does not contain any countermeasures, you are (in principle) vulnerable to the LM attack. You could post-process the mean and variance (as you suggest) by decreasing the precision, and it may be fine (this "deterministic rounding" is roughly the same as adding random noise to the lower order bits, although I think there are some mild benefits to adding random noise over deterministic rounding). But particular parameters for the post-processing have not been uniformly settled on yet.

It is worth mentioning the caveat that while LM manages to extract the secret key, for computations of more complex circuits this becomes less obvious how to do, although the indistinguishably attack still seems straightforward.