There's a spectrum from "pure spaghetti" to what I'd call "clean code enthusiast".
The sweet spot is somewhere in the middle.
I've definitely refactored code which was done by someone who was clearly a clean code enthusiast where they couldn't generate enough single line methods.
I took a lot of those single line methods, that were often used only in one place or where the name of the method was nearly as complicated as the expression that it was replacing and by in-lining them did not produce spaghetti code and which eliminated the cognitive load of that extra method.
You have to account for the cost of extracting a method, which is always additional cognitive load and the possible cost of a reader scanning through the source code to look for the definition of the method (even if its still in the same file).
When you are cleaning up clear spaghetti code the cost of the cognitive load is generally going to be much less than the benefit of removing the impenetrable spaghetti.
But at some limit you no longer have spaghetti code yet you can still continue to pull out methods which are mostly useless abstractions which give the reader more names and more overhead. At that point you're just inventing a complicated domain specific language composed of your methods which are adding pure cognitive overhead to the reader and offering nothing in terms of actual code cleanup.
Also not every way of breaking up spaghetti code is equivalent. If you use complicated abstractions in an attempt to avoid code duplication you can wind up with code that is deduplicated and abstracted and not spaghetti but completely impenetrable. I've had success with removing abstractions completely producing simple, clean but duplicated code, and then approaching the de-duplication problem by producing simple instead of complicated abstractions.
And when you extract a method you've invented it so you're instantly familiar with what it does and your rationale for naming that way, and it seems perfect and good. When someone else approaches your source code, your subjective rationale for why something was abstracted into a method and what it was named and what it does may not be anywhere near as intuitively obvious. You can generate an affinity for your own abstractions due to the familiarity of inventing them that blinds you to how difficult it is to read your own code for someone with no experience with it.
The best code isn't measured by line count of methods or anything like that, but lowest cognitive overhead on the part of the reader. All the objective measures that are offered are really trying to get at that actual subjective measurement. And every single objective rule about writing clean code have edge conditions that you need to violate from time to time to produce actual easy to read code. All rules about clean coding are going to be terrible if they're followed 100% of the time. Some rules are better and should be followed almost all the time, other rules are closer to 80/20 and should be fairly commonly rejected. When you reject a rule you should understand why the rule is there and what it costs when you reject it, and understand what benefit you're getting by rejecting the rule.
The sweet spot is somewhere in the middle.
I've definitely refactored code which was done by someone who was clearly a clean code enthusiast where they couldn't generate enough single line methods.
I took a lot of those single line methods, that were often used only in one place or where the name of the method was nearly as complicated as the expression that it was replacing and by in-lining them did not produce spaghetti code and which eliminated the cognitive load of that extra method.
You have to account for the cost of extracting a method, which is always additional cognitive load and the possible cost of a reader scanning through the source code to look for the definition of the method (even if its still in the same file).
When you are cleaning up clear spaghetti code the cost of the cognitive load is generally going to be much less than the benefit of removing the impenetrable spaghetti.
But at some limit you no longer have spaghetti code yet you can still continue to pull out methods which are mostly useless abstractions which give the reader more names and more overhead. At that point you're just inventing a complicated domain specific language composed of your methods which are adding pure cognitive overhead to the reader and offering nothing in terms of actual code cleanup.
Also not every way of breaking up spaghetti code is equivalent. If you use complicated abstractions in an attempt to avoid code duplication you can wind up with code that is deduplicated and abstracted and not spaghetti but completely impenetrable. I've had success with removing abstractions completely producing simple, clean but duplicated code, and then approaching the de-duplication problem by producing simple instead of complicated abstractions.
And when you extract a method you've invented it so you're instantly familiar with what it does and your rationale for naming that way, and it seems perfect and good. When someone else approaches your source code, your subjective rationale for why something was abstracted into a method and what it was named and what it does may not be anywhere near as intuitively obvious. You can generate an affinity for your own abstractions due to the familiarity of inventing them that blinds you to how difficult it is to read your own code for someone with no experience with it.
The best code isn't measured by line count of methods or anything like that, but lowest cognitive overhead on the part of the reader. All the objective measures that are offered are really trying to get at that actual subjective measurement. And every single objective rule about writing clean code have edge conditions that you need to violate from time to time to produce actual easy to read code. All rules about clean coding are going to be terrible if they're followed 100% of the time. Some rules are better and should be followed almost all the time, other rules are closer to 80/20 and should be fairly commonly rejected. When you reject a rule you should understand why the rule is there and what it costs when you reject it, and understand what benefit you're getting by rejecting the rule.