Six levels of abstractions, sure, if you have that many, you may want 6 functions. But that contradicts Martin when he's saying that there should be one line in an if, and everything more should be promoted to its own function. There's no way a programmer routinely writes code so terse that you get six levels of abstraction in a dozen of lines of code. Otherwise, Martin doesn't understand what an abstraction is.

Managing a stack in your head like a computer is very challenging as far as cognitive load is concerned. You don't want to jump all over the place. Otherwise, when you reach your destination, you end up forgetting what got you here in the first place.

This form of code fragmentation makes debugging an absolute nightmare, and finding sources of mutation absurdly frustrating. Good tooling can help you track where a variable is used and in which order mutations happen trivially in code in a single function. It's not as as helpful when it's spread all over the place. You can infer so much less statically if you follow Martin's advice.

I'm not advocating for 1000-lines functions here, mind you. When functions become too big, other challenges arise. What's necessary is balance, which Martin's book fails to teach.