I don't see design docs as a tutorial on how to be a better programmer using a new syntax, the goal is to flesh out a new concept built on some fundamental ideas.
You cherry picked one example of a tangled/messy block of code that they used to communicate specific idea around "left to right" comprehension and flow of the data using the new syntax. For that specifically it did a fine job.
But that doesn't mean that's the way you should be writing code in the first place, given it started with a mess and only used one piece of syntax to change it.
I will admit it's a poor example to open with. But for a design doc about exploring and debating ideas it's fine.
The way I read the proposal is that they used a real-world example from a commonly used codebase (React) to demonstrate how this feature would improve it. I think that's a good approach as features are intended to address real-world concerns, and concrete real-world examples help with that.
I don't think it's fair to say it's "cherry picking" to focus on the example they focus on themselves. They have a few other examples too, but I would say "I don't see how [NEW] is better than [OLD]" for many of those as well (and for some, I think the [NEW] is significantly worse).
Considering it was their opening example (which they reiterated multiple times) I will concede it was a poor choice. Since yes one of the top goals is selling the general idea. So it's fair the general audience would take it at face value, especially when they use it multiple times as a real world use case, it is hard to take it any other way.
Plus the doc is #1 on HN after all, which could IRL push it beyond a proposal stage if done right.
You cherry picked one example of a tangled/messy block of code that they used to communicate specific idea around "left to right" comprehension and flow of the data using the new syntax. For that specifically it did a fine job.
But that doesn't mean that's the way you should be writing code in the first place, given it started with a mess and only used one piece of syntax to change it.
I will admit it's a poor example to open with. But for a design doc about exploring and debating ideas it's fine.