I feel like Maven is doomed by its history. When Maven was created, expressing dependencies with version ranges was encouraged. But there was no lockfile concept, so that did not work well. Instead of adding lockfiles, they decided to leave the tool as it was but encourage people not to use dependency ranges. But dependency ranges are still supported, so you need a plugin to check your POM files and make sure you aren't using them. Dependency resolution is recursive, so indirect dependencies might still use version ranges, so you need a plugin to detect those ambiguities so you can pin those versions yourself in your own POM. If, despite your best efforts, you end up with an indirect dependency being specified with two different versions, Maven doesn't mind that at all (by default, if will package both, and leave it up to chance which one gets loaded at runtime)[0] so you need a plugin to detect that situation as well.
To sum up, we realized the default behavior was wrong over a decade ago, but rather than change the default behavior of the tool, maybe add a new version of POM files where sanity is the default (it's a versioned format! c'mon!) or a new non-XML file format that triggers a new mode of operation, they stuck with the legacy behavior, forcing every new project to include a bunch of XML boilerplate just to get the behavior that they realized should have been the default 15+ years ago.
That was the situation last time I used Maven, anyway. I'd love to hear that Maven has since added a new mode of operation that is sane by default, without needing extra plugins and configuration, and doesn't use XML.
I can't comment on Gradle. I've worked on a couple of Gradle projects, and the build files were a mess, but I don't know if they needed to be a mess or it was just bad luck.
[0] Actually I don't remember if the default is to pick a version at build time or to package both, but I know the latter is possible because I saw it cause many production issues before we configured a plugin to prevent it.