Во-первых, в отличии от Ant, Maven хорошо интегрируется со всеми основными средами разработки. Если в вашей команде предпочитают работать в разных средах разработки, то не нужно ограничивать - пусть каждый пользуется тем, что ему нравится. В любой среде проект открывается сразу уже настроенный.
Во вторых, хорошо, если сборка проекта может происходить совсем без IDE. Для сборки Ant'ом это значит поддерживать скрипты для сборки, которые дублируют информацию в файлах проекта конкретной IDE. Зачастую build.xml (файл сборки в Ant) устаревает, и перестаёт работать т.к. им каждодневно не пользуются.
Во всех Ant проектах в которых я участвовал, работа с библиотеками организована следующим образом: в директории проекта создавалась папка lib и туда копировались все jar файлы библиотек. Проблем нет до тех пор пока вся библиотека содержится в одном jar файле. Но дело в том что сложные библиотеки могут включать в свой состав другие библиотеки(зависимости). К примеру hibernate содержит внутри себя 16 библиотек. Вот управлять такими библиотеками с зависимостями сложнее.
Представьте что в вашем проекте давно используется Hibernate и Struts. Тут вы решили обновить версию Hibernate чтобы воспользоваться новыми возможностями новой версии. Кажется всё просто - сравниваем версии hibernate, копируем в директорию lib все библиотеки из нового hibernate. Если в lib есть такие же файлы библиотек со старыми номерами в названии файла то пожалуй их нужно удалить. Всё вроде просто, но ранние версии hibernate содержали в качестве зависимости commons-logging, а в новой версии вместо него используется slf4j. Получается commons-logging уже не нужен, можно удалить. А вы точно уверены что можно удалить? А если commons-logging успользуется в другой библиотеке? И действительно, внутри struts есть commons-logging. удалять нельзя - иначе получишь ClassNotFoundException во время выполнения программы. Тут я вам описал случай с двумя библиотеками Hibernate и Struts. А если библиотек много? Пожалуй тут лучше воспользоваться ivy..
Maven хранит зависимости в pom.xml. И в отличии от Ant'овской системы сборки* здесь информация о зависимостях не теряется. В большинстве случаев апгрейд библиотеки сводится к изменению номера версии в pom.xml. Всё остальное Maven сделает сам.
Здесь приведён часто встречающийся способ сборки проекта в Ant, но он может значительно отличаться.
К недостаткам maven следует отнести его большую сложность и дополнительное время для изучения если вы ещё не знаете Maven.
Есть опенсорсные библиотеки, которые собираются не Maven'ом, и они попадают в центральный репозиторий обычно позже, чем выйдет официальный релиз. Тут можно либо подождать, когда они всё-таки попадут в центральный репозиторий, либо добавить их вручную в локальный/корпоративный репозиторий.