I wouldn't go so far as rbt to say that it's unmaintained, but the development attitude is that of maintenance (features like Java 9 modules compatibility) rather than active development. Gradle has improved by leaps and bounds very quickly; the Gradle build daemon makes build tasks feel much quicker and powerful in day-to-day practice, and is clearly now the preferred tool for new projects.
Look, if you have a lot of pre-existing Maven builds then of course the story gets more complicated. Large enterprises usually have higher priorities than spending large $X on any kind of migration that's not absolutely necessary, including the costs for retraining dozens or hundreds or thousands of developers to use a new build tool and to overhaul tooling that was built on top of the old solution (e.g. deployment scripts invoking mvn deploy and Maven reports), and can often result in choosing options that are technically worse but organizationally better.
What I mean is when you have the freedom to choose a new technology stack because it's a new project - because a lot of companies still won't give you that freedom even with new projects.
Unless you have some objection against Gradle itself?
Maven doesn't require 2 GB, a SSD, a background daemon and different dependency commands to be fast.
Also Maven has never been four years in a row subject of build performance at multiple conferences.
For those that don't suffer from XML allergy, Maven is quite alright, IDEs can
provide completions that actually make sense and nice graphical tooling for dependency management.