Because there are scenarios where pattern matching (or instanceof) is the better and more ergonomic thing to use. One obvious example I can think of is event handling.
If anything, this is _not_ something JS devs are asking for, but rather devs using functional languages.
I also think of API ergonomics. Unspecified input with the same single endpoint, while under the hood will be absolute spaghetti, from a developer adoption standpoint can be make or break.
And if you're strongly typing your system rather than relying on strings, extra so.
Exactly, this is what OP was trying to point out. With the record matching feature, you don't need the extra abstract base class anymore.
This is not to say that abstract base classes are never a good idea, but sometimes in Java they were only there for the convenience of one handler method, to prevent the use of instanceof.
This didn't improve readability. That's when the record matching can be a good improvement.
Sometimes it isn't desirable to scatter the logic across many classes, or conflate the data and the handling. The Java world has the "visitor pattern" to help deal with that, but its double-dispatch is clunky, complex and verbose. Pattern matching just generalises switch and makes it more useful. Java is genuinely a better language with this change.
If anything, this is _not_ something JS devs are asking for, but rather devs using functional languages.