I was with you on 1 and 2, but you lost me on 3. In the props example, where it came from is generally not your concern when you are reading or modifying those lines - and when you do have that concern about where they come from, the destructuring version is easy to follow. Personal preferences to be sure though.

I feel many fluent API's are guilty of something similar. You gain terse, one-line magic statements that accomplish a lot; you lose discoverability and meaningful object-oriented class names.

For example, ElasticSearch's NEST API client uses a fluent-style API to setup configuration and mappings. It started out well, but then I got lost in a forest of nested callbacks on various mystery objects. It was a bizarre way to build what should have been a tree of strongly-typed POCO's that have a 1-to-1 correlation with the server-side concepts. Worse, I didn't see a way to dynamically manipulate the (hidden) result. Better to use the low-level API and a little reflection to compose the required JSON manually.

[On the other hand, I can think of successful fluent API's: .NET's StringBuilder works because it is super simple (only returning instances of itself). The IEnumerable extension methods (created to support LINQ) work because their broad-applicability justifies the effort to learn.]

In my experience no one likes seeing single-letter variable names (except for i, but I have even heard criticism of using e to represent an error). As for your second example, whether it provides clarity or convenience is entirely situational. If you have a long render method then specifying that a variable is coming from props may be helpful but the most common standards call for props to be passed to a functional component that has a single responsibility, i.e. destructuring props and rendering its respective values.

Sorry if I missed something but I also don't see an endorsement of bad variable names in the OP's handbook. The comment just seems a little out of place, thought I mostly agree with it.

I prefer a = w * h. I actually wish I didn't, but I studied a mathematics undergrad, and when I see the token 'area' it means, to me, the concept of area, whereas 'a' is a variable which represents the quantity in context.

Indeed, it's more common to write 'let the area be a, the width be w and the height h; then a = w * h' than it is to write 'area = with * height' when expositing in a maths textbook. This is a really hard habit for me to get out of, even when writing code.

Readability is subjective. There's no universal notion of "readability". Code that looks perfectly fine to one person, might looks like pure gobbledy-gook to the other. It's important to recognize that, whenever we're talking about "code readability".

On your last point, it's easier to see all props the component depends on when you destructure them upfront like that.