Surely that's completely missing the reality that the reason code is hard to understand is virtually never because of whether you're using some particular syntactical feature like ternary expressions* - it's because the features you're working on are complex and there's a bunch of interactions between lots of different parts of the software, and it takes a while to get your head around all of them. On the other hand, poorly named functions and variables, poorly constructed interfaces, tight (but non-obvious) coupling between different units of code and a lack of a straightforward way to walk through various paths of the code (e.g. via unit tests) are the sorts of things that make code especially incomprehensible and hard to work with, and for that reason, the sorts of things I'll flag in a review. If I see syntax I think looks a little ugly or unnecessarily "clever" I'll usually add a comment and a suggestion but it still generally gets a tick.

(*) even the example given in the article of an obviously unnecessary use of "reduce" is pretty rarely representative of the sorts of reasons code is hard to understand, though I have come across similar things in 3rd party open-source libraries and the like - I would say though these days you could almost certainly get ChatGPT to explain particularly obscure uses of map/reduce etc. Whereas it's never going to be able to explain high-level behaviour that requires the entire codebase.