Why not? What about, say, the API Copyleft License, which reads very much like Parity, but permits building closed applications? https://apicopyleft.com/
That license allows everything Parity does, plus one more: creating closed applications.
Taken on its own merits, I would indeed consider MPL 2.0 inadequate as a general-purpose copyleft license. Formally, you could argue that it's even weaker than the API Copyleft terms. As such, it's hard to recommend MPL for a project standing alone.
It understands, however, its position as a compromise which makes the underlying goal of its approach to copyleft untenable. Despite that, tries to preserve the ability to incorporate downstream changes through one degree of separation. The difference in expectations is palpable. The implied flow for publishing derivatives of MPL work is to distribute also under MPL, with the option of separately licensing non-Covered Software presented as a concession to tightly define the scope of the license. The implied flow for publishing derivatives of API Copyright Licensed work seems to involve carefully considering how much you can get away with under the listed exceptions, with the option to not share alike presented front and center.
The distinction is essentially irrelevant to anyone approaching licensing from a legalistic perspective, bet defaults matter for everyone else.
The use case for MPL and SSPL was broadly the same: selectively apply permissivity for the primary build-on use case (browser plugins, applications) to stoke adoption and copyleft to other use cases (forks, hosted offerings) as a bulwark against competitors (Microsoft, AWS). In drafting and presentation, I thought SSPL failed to communicate that heritage. So I wrote what became the API Copyleft License.
Why not? What about, say, the API Copyleft License, which reads very much like Parity, but permits building closed applications? https://apicopyleft.com/
That license allows everything Parity does, plus one more: creating closed applications.