Build tools like lein or Maven attempt to build a "declarative" definition of a project and then apply a set of plugins to that model using an implicit lifecycle. In reality, simple projects don't need that complexity and complicated projects only match 80% to either the lifecycle or the plugins available, so you end up wedging imperative things onto the build, hunting down obscure plugins, or hacking your own. Other build tools (like boot, or even Ant) acknowledge that builds are actually programs built from similar tasks.
deps was designed to find a sweet spot in the middle of this with deps defined as data, aliases capturing program executions as data, but builds as programs. As such, the scope is drastically narrowed in deps to just a) building classpaths (by resolving dependency graphs) and b) launching programs.
As such, this tends to be a dramatically simpler model to start with (your initial deps.edn can be empty), and a model that is easy to understand as you scale up. I think there is more to do in how we model "tools" (esp tools shared across projects) and program composites, but nothing prevents you from building these yourself if needed (as you have the full power of Clojure at your disposal).
You can find a pretty comprehensive list of deps.edn tools at https://github.com/clojure/tools.deps.alpha/wiki/Tools