My impression of Scala from a few years ago was that the language itself was so flexible (ranging from 'not quite Java' to 'not quite Haskell'), that you'd really want strict adherence to a particular style (or set of features) for a codebase to have hope of being maintainable.
They'll write 500 lines of inscrutable framework code to save having to write 5 lines of boilerplate 3 or 4 times.
Scala's flexible enough that the old lisp pitfalls apply (though not nearly to the extent of lisp). That is to say, learning the language itself doesn't necessarily mean you're going to have any sort of grasp on a particular codebase, or even a different part of the same codebase.
There's a particular style of scala that involves bringing in and stringing together dsls. Which is both extremely powerful, and can make code completely unreadable to someone who doesn't know that exact combination of packages.
If you're not careful, your bus-factor is 1 and even the other seniors won't have any idea what's going on right away.
This is main point which, more often than not, turns out to be a negative for Scala (there could be specific circumstances where this may be a big positive but, usually not).
The rule of thumb for me for Scala code is, only follow constructs/idioms/style mentioned in the Scala Book[0]. Most of the time, everything else is unnecessary trouble.
[0]: https://docs.scala-lang.org/overviews/scala-book/introductio...
I mean, I think that those circumstances would be a solo passion project.
I still think scala is a beautiful and expressive language. But I think that expressiveness actually inhibits collaboration. If you're expressing novel thoughts in a novel way, you've added syntactic overhead to the already significant conceptual overhead.
So, yeah. Quite personally rewarding, but I can't recommend it for a work project in good faith after having worked in it. Enterprise projects should probably use java/kotlin if they want to be on the jvm, or go/python/js if they don't.
As a new member of the team, I took the opportunity to cleanup when I got a similar assignment, which took an extra day. Subsequently when another dev had to do a similar task, he used my setup and basically had to make changes in 3 config lines which took a minuscule fraction of what he would have spent doing copy/paste and modifications. He was happy and I was puzzled why none of them bothered to do it for so long; my cleanup wasn't rocket science and any of them could have done it.
As with all things, balance is the key.
A team that gets shit done will later look back and see that what they've done is shit.