It depends on many things. Struts has a particular problem in that it tends to get locked in memory - it is possible that objects are not released or otherwise expired so the JBoss undeployment process cannot eject the existing class. In this case, it is probably generally better to place the library in the lib directory (usually the instance lib rather than the common/bootstrap lib).
In general, if you are using the library with many applications, you can save memory by sharing the library - you may have problems in certain instances where the library tries to read a configuration that you expect to be in your application context but because the library is shared, it does not do as expected.
If your WAR/EAR may be deployed on an application server that doesn't have the library (for example deploying on many app servers besides JBoss), you may want to consider packing with the library - on the proviso you don't have the issue as per Struts. Also note that some app servers do have these types of resources already bundled with them as well.
YMMV. My advice based on deployment experience is to have a flexible build process (Ant is good).
Thanks for your reply, it's good to hear that this is actually a problem and that I was not imagining the whole thing. :)
I am using ANT, and I already have some targets that set up JBoss configuration directories properly (i.e. <jboss_home>/server/). I modified these to detect struts/commons and place the jars in <jboss_home>/server//lib, which works fine. You are correct in that I will need to make some equivalent change in order to deploy on a different app server.