Without sealed classes it's impossible to enforce most interesting invariants. If anything the other way is a mistake.

Reasonable arguments can be made that sealed classes should be the default.

From https://news.ycombinator.com/item?id=16952659 (and all the related links to that comment and the original article - The Impoliteness of Overriding Methods)

IMO sealing for classes is unnecessary, so long as methods are opt-in for overriding (e.g. as in C++ or C#, where you need to explicitly say "virtual"). If you can't override anything in a derived class, how can you break invariants?

Yeah - personally I think languages should allow a lot of constraints like sealed classes (it makes your intent clear, and can allow extra optimizations, that's good!), but highly-risky "escape hatches" need to exist because they solve real problems.

"Fork and modify" is a very capable alternative, but it's far, far, far more costly than "monkey-patch this one time issue that'll be fixed next week". And some languages make it extremely painful to achieve, often requiring significant code rewriting, and which sometimes make contributing back to the source-library significantly harder. And when such hacks hang around longer for a week... well, sometimes that's fine, sometimes it's not, and the library author is not the one who should be making that decision. It's my program, it should do what I tell it to do.

A sealed class ought to have no methods, so it is plain old data. Then there's no purpose to overriding it.

I think you're thinking of `record` classes? Sealed classes are about constraining inheriting or implementing to only approved types - using sealed is pointless without overriding of some kind. Unlike in some other languages, where sealed is closer to java's final classes, i.e. stopping inheritance.

In Kotlin, I use sealed classes as a substitute for union types, and that means for the most part they have no functions.

If they are like Scala's I do mean sealed.

You shouldn't need to mock a sealed class in the first place. Consider them like a more powerful enum or an algebraic data type.

You wouldn't mock en enum either (hopefully).

PowerMock is a mistake on its right own; I outright reject pull requests if anyone attempts writing unit tests that need modification of final state.

Don't think of it as a less powerful class, think of it as a more powerful enum. At least that's how it's meant to be used. It's a good feature in other languages, and like you said, "final" already exists, so you're no worse off on that front.

I've seen projects where the whole architecture/design was screwed just because someone wanted to mock >>everything<< during unit testing...

Sealed classes are better enums, akin to swifts, etc and are built to allow pattern matching and error reporting on missed cases.