The differences begin in the nomenclature, we call those of the Tomcat category of web server and others like Jboss and Glassfish of conteiner. A container generally adds more functionality than the basic specification of a web server. For example: administration interfaces, connection pools, load balancing, are features that are already ready and available in general containers that will not require too much administrator knowledge to make them work. In addition they already have a set of pre-installed libraries, many of them related to these services that are homologated by the server. For simpler examples: In tomcat when you need to use JPA for example, you need to include the libraries (defining the versions of them) from vendors like Hibernate, EclipseLink, etc. In the case of JBoss it already has Hibernate as standard and does not need to be included via application. In practice, what happens is that the container manages the libraries and thus guarantees their functionality and compatibility. If you have more than one application on the same server they will be using the same version of each library provided by the container.
Until recently, because of "uploading" all services at startup, JBoss was much slower to start than Tomcat. On the other hand, the first access to the application in Tomcat would be slower than in JBoss, since services start together with the application. Currently in JBoss 7.x or WildFly 8.x the services are initialized on demand, according to the need of the application. So Tomcat's rationale for being more "fast and light" is not exactly valid for all cases.
A basic requirement that you would use to choose a server, apart from the level of knowledge about each of them of course, is the need of your application for the services that each offers. For example, if you are doing load balancing on a container you can do this in a very trivial way using the administration interfaces. So you should list what features your application needs and see if you need a server or container.