There is a definition of "unreadable" missing from the bullet point list at the top. This is code that is known to be correctly functioning, but the implementation of that functionality is objectively obscure (this is not equivilant to the second bullet point). In my experience you see it most in code that is old and has had many programmers work on it. For example, your reading a function trying to figure out how it could ever return a correct value - and yet good tests show it does every time. You realize 100 lines can be replaced by a hash lookup such-n-such, so you make the change expecting the tests to fail because you didn't understand something, but nope, you were right - simple lookup was all it needed. How does code like this come to be? It grows organically. The latest minor tweak is a tiny blip in the long twisted history of the functions existence.

This might seem like a minor addition to the list, but I think it's an important one. And it has a deeper philosophical implication: if you end up with a "Rube Goldberg machine" chunk of code it is not simply stylistic preference, even if the code functions correctly. In other words: you should not make the claim that just because it functions correctly that it is "correctly written". You certainly can make that claim (and I have seen many do, and I have done so myself).

There is code that is complex because it needs to be. There is code that is complex even though it doesn't need to be. If you don't actively prune the second type, it will grow all by itself and take over your garden.