One of the side effects of the "obfuscated C" thing is that some people go too far the other way, damaging the readability of their code as a result.
Refactoring into functions (ie breaking the code into separate chunks) can easily hide structure that helps with readability. Moving complexity into the call graph doesn't eliminate that complexity, so the important thing is whether the high level stuff still makes immediate sense when you're seeing the names of the low level stuff, not the implementation. "Immediate sense" can include all kinds of details - is the upper bound n, or n+1, or n-1 etc etc.
If there's a sensible function name that explains what the function does, so you're compositing abstractions, and so that it's obvious when the parameters are correct, that's good.
If you're refactoring due to a nesting count or a line count - purely because of an inflexible style rule and ignoring actual readability - I don't want to maintain your code.
The problem with judging readability is that you know what the code is intended to do as you write it. It's not the same as understanding something someone else wrote, or coming back to your own code 5 years later. There's a lot of rules and guidelines intended to counter that. Some are important, but some go too far.
My view - over time, you'll learn by experience what is genuinely readable. Don't disregard the common style rules, but don't obsess over the thousand-page style guides either. There's lots of good advice out there, even in those thousand-page style guide books, but you can't write code at all without breaking someones pet style rule.
Of course if your employer requires that you follow certain rules, you follow them - or if you really can't, find another employer.