As asked: "Is it usual to require all application namespaces via tools.namespace?"
No, definitely not "usual".
It's not particularly usual to have multimethod/protocol implementations spread across so many namespaces -- that are otherwise not required by code that uses those multimethods/protocols -- that a list of requires of them is particularly "noisy".
tools.deps
has a number of provider implementations spread across namespaces but it requires all the built-in ones in the "entry point" namespace for other code that uses the library. See https://github.com/clojure/tools.deps.alpha/blob/860bc7e3e310380b3baf9b43b05d343f3ae812f6/src/main/clojure/clojure/tools/deps/alpha.clj#L17-L22 -- I don't know whether you'd consider that "noisy"?
If you really do have a "lot" of implementation namespaces that are not likely to be required by any other code, and therefore need loading somewhere near startup, then I would first consider creating an interim namespace that does the requiring and then just require that in your initial namespace.
If that still seems too noisy, I might consider using tools.namespace
to automatically find and load just the implementation namespaces, assuming they follow an appropriate pattern. But I've never run across that need in eight years of production Clojure so far.