The @Clustered annotation currently has 2 orthogonal meanings:
1. If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
2. If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.

This is confusing.

If I want to replicate the state of my SFSB, I have to annotate my bean with @Clustered. However, this annotation could be ignored if my server profile does not support it. So, effectively, my server profile ultimately dictates whether or not my SFSB's state gets replicated. If that's the case, why bother with requiring @Clustered at all?

Additionally, EE7 adds spec support for specifying whether a given SFSB is passivation-capable. By default, the spec dictates that SFSBs are passivation capable. According to Section 4.6.5 of the EJB 3.2 specification (the section that describes passivationCapable):
"Note: application server vendors may use passivation as a technique to provide high availability of stateful session beans by replicating their state from one JVM instance to another across which the container is distributed."
Given this, it only seems natural that a server that provides high-availability to a SFSB that is passivation capable by default would have its state replicated by default.