Since fairness cannot be modeled, does that mean I cannot prove that a voting scheme, for example is fair (that is, that either the protocol finishes execution and everybody learns the result or nobody learns anything)?

In the UC model, fairness is a property of the ideal functionality itself. A "fair functionality" is one that gives output to everybody or to nobody. In SUC you are not even allowed to talk about a fair functionality (all communication is inherently "unfair"). If a protocol securely realizes a "fair functionality", then you would say that the protocol is "fair." Since you're not allowed to talk about "fair functionalities" in SUC, you are correct, you cannot prove fairness properties in SUC.

And does the second part of the quotation mean that I cannot model the use of encryption and signatures in whatever protocol I'm using? I doubt that, but the wording used in the article got me a bit confused.

The short answer is, no you are not prevented from using encryption/signatures in your protocols.

The long answer is: we don't typically define security of encryption/signatures using the language of MPC, since these schemes consist of noninteractive algorithms. Yet it is possible to define an ideal functionality $F$ with the following property: "an encryption scheme is CCA secure if and only if that scheme is a secure protocol for $F$ (after translating some syntax appropriately)."

Such a functionality $F$ is really weird compared to typical MPC functionalities. When party $P$ talks to $F$, the response only goes to party $P$, and the adversary gets no notification about this exchange between $P$ and $F$! This models the fact that when $P$ wants to encrypt, he does so inside his head, and doesn't have to talk to anyone (how can an adversary know when I'm encrypting stuff in the privacy of my own brain?).

The SUC model can't handle this kind of functionality. In SUC, when a functionality generates an output for a party, the adversary must always learn the fact that output was produced (maybe he/she doesn't see the contents of the output). So in SUC you can only write a functionality for an interactive "traditional MPC" kind of thing.

So all this is saying is that you can't talk about weird UC functionalities that try to characterize CCA encryption / existentially unforgeable signatures. Again, this is a restriction on the kinds of functionalities you can write in SUC. There is no restriction on the kind of protocol you can write. You can definitely use encryption/signatures in your protocol. In that case, your security proof should then use the standard, game-based definitions of security.

Since fairness cannot be modeled, does that mean I cannot prove that a voting scheme, for example is fair (that is, that either the protocol finishes execution and everybody learns the result or nobody learns anything)?

In the UC model, fairness is a property of the ideal functionality itself. A "fair functionality" is one that gives output to everybody or to nobody. If a protocol securely realizes a "fair functionality", then you would say that the protocol is "fair."

In SUC you are not even allowed to talk about a fair functionality. All communication from the functionality is inherently "unfair" as part of the underlying communication model. So you are correct, you cannot prove fairness properties in SUC.

And does the second part of the quotation mean that I cannot model the use of encryption and signatures in whatever protocol I'm using? I doubt that, but the wording used in the article got me a bit confused.

The short answer is, no you are not prevented from using encryption/signatures in your protocols.

The long answer is: we don't typically define security of encryption/signatures using the language of MPC, since these schemes consist of noninteractive algorithms. Yet it is possible to define an ideal functionality $F$ with the following property: "an encryption scheme is CCA secure if and only if that scheme is a secure protocol for $F$ (after translating some syntax appropriately)."

Such a functionality $F$ is really weird compared to typical MPC functionalities. When party $P$ talks to $F$, the response only goes to party $P$, and the adversary gets no notification about this exchange between $P$ and $F$! This models the fact that when $P$ wants to encrypt, he does so inside his head, and doesn't have to talk to anyone (how can an adversary know when I'm encrypting stuff in the privacy of my own brain?).

The SUC model can't handle this kind of functionality. In SUC, when a functionality generates an output for a party, the adversary must always learn the fact that output was produced (maybe he/she doesn't see the contents of the output). So in SUC you can only write a functionality for an interactive "traditional MPC" kind of thing.

So all this is saying is that you can't talk about weird UC functionalities that try to characterize CCA encryption / existentially unforgeable signatures. Again, this is a restriction on the kinds of functionalities you can write in SUC. There is no restriction on the kind of protocol you can write. You can definitely use encryption/signatures in your protocol. In that case, your security proof should then use the standard, game-based definitions of security.