People get such hate-boners for "Clean Code" specifically, it's weird. I once thought they might have had a point until I read the book and, while I found much to disagree with, it's actually not a bad book (I have more negative things to say about an oft-cited "counter" book, "A Philosophy of Software Design"). I think there's useful things to learn and consider in it, and even though I think you can do better by thinking for yourself, the average bar is so low among programmers that I think many would be improved by substituting their non-thinking flailing around for non-thinking dogmatic following of such books' rules of thumb. Working in such a dogmatic environment would be oppressive, though you at least have a framework to move beyond some of it. Presumably such environments exist and maybe that's a source of some hate, though I've more often seen oppressive environments that e.g. won't accept any Python commits which violate the changing PEP8 lint checks despite PEP8 itself allowing for differences of opinion.

There's even more context that people should consider. From earlier in the same chapter:

"The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. This is not an assertion that I can justify. I can’t provide any references to research that shows that very small functions are better. What I can tell you is that for nearly four decades I have written functions of all different sizes. I’ve written several nasty 3,000-line abominations. I’ve written scads of functions in the 100 to 300 line range. And I’ve written functions that were 20 to 30 lines long. What this experience has taught me, through long trial and error, is that functions should be very small."

My relevant point here is that it's clearly not a book full of careful supporting arguments and cited research or really even hyper-specific non-fuzzy rules. It's a style guide for how to make "clean code", built from the author's experiences and idea of what "clean" means. Disagreement is natural, and often also based on nothing more than different experiences rather than careful arguments/research. It's also very contextual, as the book itself notes in places -- different languages, tooling, or emphasized programming paradigms will produce different ideas of what clean means.

For the issue about function arguments, in the full context it's very clear that in Java we don't idiomatically interpret the implicit "this" to be an extra function argument as we do in idiomatic Python with its explicit "self". Immediately after the quoted sentence on number of arguments is this: "Consider, for instance, the StringBuffer in the example. We could have passed it around as an argument rather than making it an instance variable, but then our readers would have had to interpret it each time they saw it."

That the bytecode for a method using an instance variable includes an "aload_0" instruction to load up "this" and "getfield" to get the instance variable value is an implementation detail. Would it have been better, from a purely functional perspective, to pass the StringBuffer around explicitly anyway? Maybe. Same maybe when it comes to unit testing concerns. Anyway, I don't see much complaining when function bodies make use of implicit built-ins like + or - or sin() or PI, instead of passing all such things as explicit arguments. That way leads to Enterprise FizzBuzz in the Java equivalent.

Sure, data not part of the method body has to come from an "outer scope", but this is not "usually a global" but an instance var, and in the very worst is a package-namespaced var. Is it a great sin to lift something into an instance variable? No, not in Java. And even for true 0-arg functions (static methods), the data can come from the method body itself. This is naturally part of the style advocated throughout the book, where you might have e.g. 10 lines of printing out some literal strings (perhaps a little help manual), you can extract those ten lines into a standalone 0-arg static method and the original method will be shorter and cleaner.

Edit: one last thing for consideration, Linus has written in the kernel coding style guide "...if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program." Is he an idiot for making such a statement? Is it a silly thing to say?