I'm not saying you're wrong nor will I argue about it as in the end it really comes down to taste I feel. To me, and perhaps to others, these things make a language harder to read/use, regardless of how pervasive...
While some of it can come to taste, I think having higher abstractions (as long as they don't leak) is beneficial to reading/using a language. Like, objectively.
And foreach vs for is not a leaky abstraction. Nor is pattern matching vs traditional checking and extracting the values. So their value is not geting lost on having corner cases that the equivalent "based on primitives" code wouldn't have. If anything they make the operation even more explicit.
So I think a lot of it comes down to getting familiar with them.
While something made of "first principles" might be more instantly familiar, it will be harder to reason about because of its low-level ness as the code size increases.
Case in point, assembly. It's quite primitive language with very few constructs, so it's easy to learn to use. But an actual high level "if" or function call is much easier to grasp at once than checking 10-20 lines that implement the same thing in assembly (even if you have trained yourself to see the assembly "pattern" for a function call, etc).
To expand on this: isn't what Go does with built-in channel and parallelism primitives similar to that?
They sure didn't exist in C. But people see the value of having this higher level abstractions.
So, why draw the line on Channels and Goroutines, and not add pattern matching in there? Just because Go already came out offering the former?
If anything, pattern matching is even more applicable to the work we do day-to-day, than channels and goroutines are.
Millions of people write programs without parallelism/concurrency every day, but nobody writes programs without pattern matching. They just do it by hand with lots of if/else and various manual extraction techniques, if their language doesn't offer it.
