1) stateful session beans must maintain their identity and state between method calls. If such a bean has not been accessed for some time then the container can elect to passivate it. This means its state is preserved somehow outside of the JVM (typically written out to a disk file using java serialization) and it's resource usage (memory) is recovered. The container will activate it again (deserialize it) when the SFSB is accessed again. The SFSB is therefore able to scale better (more "instances" of it can fit in a single JVM, but there is an associated time and I/O penalty).
2) stateless beans need only exist for the duration of single method call, following which any resources that they use can be reclaimed. More commonly a number of them would be maintained in a pool and temporarily made available to deal with a particular method call. As such stateless session beans have little or no direct impact on scaleability.
Stateful session beans are used for quite different purposes than stateless session beans. You would not choose one over the other because of scalability concerns.
3) Serialization is the mechanism that Java uses to read and write arbitrary object state. The instance variables associated with a SFSB must be serializable (aside from some documented exceptions). This not only allows the SFSB to be passivated/activated, but also allows it to be migrated to other JVM instances in order to support fail-over and/or load balancing.
With respect to SFSBs, passivation and activation could be done in other ways, but serialisation is mandated by the EJB specification.