JBoss это сервер J2EE приложений. Он обеспечивает полностью весь набор J2EE решений.
Tomcat же является только контейнером сервлетов. Он реализует спецификацию Servlets и все сильно с ней связаные: JSP, JSTL, JAAS, JNDI.
В отличие от JBoss на Tomcat не удастся (без дополнительных телодвижений) задеплоить приложения связаные с EJB, JMS. Связаная с EJB встроеная поддержка кластеризации. Поддержка не аховая, но какая-никакая а есть.

Кроме этого много отличий в удобстве конфигурирования и некоторых других фич. Как например широкий доступ к разлиынчм фичам через JMX, удобная настройка логов и пр.

В приниципе на данный момент существует не так много причин использовать просто Tomcat а не JBoss. С JBoss многое проще и удобнее.

Geronemo1. У меня на работе делается несколько серьезных проектов (наподобии сайта госуслуг, но меньшего масштаба). И там приложение основано на Spring и работает на Томкате. При этом все необходимые фичи присутствуют, все выглядит довольно красиво и работает эффективно. Хотелось бы понять, что же такое сервер Apache Tomcat - это сервер для Java SE, на который можно с помощью Спринга и Мавена навешать функций, чтобы получить почти полноценный Java EE. Или же это сервер, предназначенный для чего-то среднего между Java SE и Java EE. Или еще какие-то варианты

Да - Tomcat это среднее между JSE и JEE. В последней версии JEE появились профили. Tomcat, вроде как, JEE Web Profile.
TomEE это сервер на базе Tomcat, на который навернуты разные реализации JEE от Apache.
Не понял вопроса про навешивание через Maven и Spring. Spring не реализует JEE. Но можно другими решениями интегрироваться в Spring и получить аналогичную функциональность.

Geronemo2. По поводу EJB. Неужели это настолько важная штука. Я тут на досуге играюсь с EJB и ничего сверхъестественного в этом не вижу. Например, у меня REST веб-сервис вызывает бин, который занимается обработкой данных и взаимодействует с БД. Но я ведь точно также могу тупо скопировать содержимое этого EJB класса в обычный класс и из REST сервисов дергать методы объектов этого класса.
Суть в том что JEE пытается предоставить кучу готового сервиса из коробки. Транзакционность, кластеризация и пр. Задумка в том что ничего из этого настраивать не нужно. Достаточно просто понимать как правильно писать EJB чтобы не сломать. А сервер уже позаботиться об остальном.
По факту же выходит, что если вдруг какой-то нюанс JEE спецификацией не покрыт, то нужно либо завязываться на сервер, либо самому упорно бодаться с проблемой. Например, в старой версии JEE они забыли включить интерцепторы в CDI managed beans. Или вот кластеризация, например. В одной из старых версий JBoss HttpSession реплицировался на все ноды кластера. И простой возможности реализовать более оптимальный подход не было. JEE спека никак не регламентирует кластеризацию. Она просто должна быть и всё.
И таких проблем на крупных проектах всплывает не мало. Они называются JEE corner cases.