So a few points to this-
SPAN is actually Cisco-specific terminology. The generic is just called port mirroring.
There is huge variability in terms of the behavior of port mirroring implementations across different hardware. As an example - in a surprising number of platforms (across different vendors) oversubscribing the amount of traffic being mirrored to a given port can actually cause packet loss on otherwise undersubscribed ports.
Keep in mind that mirrored traffic often won't include packets with errors (..they get dropped at ingress on most switches) and that there's also no guarantee that packets will be delivered in order or that duplication will always be suppressed.
There are also limits as to the number of mirroring sessions, the number of ports/VLAN's being mirrored and whether the sources are monitored bidirectionally (ex: some switches might allow mirroring input from all 24 ports on a switch not input+output).
So - depending on the switch platform in use there are a bunch of things that can be used to control load and otherwise make the problem a lot more approachable. As Ron mentions, something like Netflow or sFlow can be a great way to go but won't provide a packet-by-packet level of analysis or allow diving into packet payloads.
Being careful with the application of mirroring through the use of ACL's can explicitly exclude/include traffic based on the problem being solved. Some platforms also allow for the truncation of mirrored packets, which can also vastly reduce the sheer volume of information being managed.
Another interesting approach is the use of ACL's to copy/redirect interesting traffic on an in-line basis. This is very different from port mirroring and ends up looking a lot more like policy routing but, again, like much of the above is incredibly hardware dependent.
There are also item like in-line taps that can physically copy the traffic on a given link to your analyzer. This is almost invariably a better solution to a permanent requirement for full traffic visibility but is obviously a lot more expensive and a lot less flexible.
In terms of actual use I tend to see larger organizations focusing first on natural choke points - switch uplinks, routers, firewalls, etc and then adding a capability to look at edge ports on an as-needed basis. Obviously use-cases vary but the sheer volume of data that can be generated can be overwhelming.