I'm beginning to feel we're no longer talking about Clean Code being bad, but about people following ideas they don't understand, which is not related or caused to any particular book.

I've found it's mostly two things: readability (ironically) and performance. I'll describe a few crude examples, but I won't get too much into specifics, otherwise I might as well write another book myself.

The performance part is simple: its excessive reliance on polymorphism and the presence of several levels of abstraction just doesn't allow for good code generation. I've seen 10x+ performance improvements by dropping all of the above, with often minimal loss in readability; on the contrary, oftentimes the code became more readable as well.

The readability part is harder to explain; not only because it depends on the codebase and the problem at hand, but also on the coding style each programmer has (though in my opinion, in that particular case it's the programmer's problem, not the codebase's).
I like to think of codebases as puzzles. To understand a codebase, you need to piece together said puzzle. What I've found with Clean Code codebases is that each piece of the puzzle is itself a smaller puzzle to piece together, which isn't ideal.

Functions

They should be small and do one thing

I generally disagree, not because those ideas are wrong, but because they're often too limiting.
What often happens by following those principles is you end up with a slew of tiny functions scattered around your codebase (or a single file), and you are forced to piece together the behaviour they exhibit when called together. Your code loses locality and, much like with CPU cache locality, your brain has to do extra work to retrieve the information it needs every time it needs to jump somewhere else.
It may work for describing what the code does at a high level, but understanding how it works to make meaningful changes will require a lot more work as a result.

Don't repeat yourself

Once again, it makes sense in principle, but in practice it often creates more problems. I agree that having massive chunks of repeated code is bad, no questions about it, but for smaller chunks it may actually be desirable in some circumstances.
By never repeating code, you end up with functions that are over-parameterized to account for all possible uses and combinations that particular code snippet needs to work with. As a result, that code becomes more complex, and the code that calls it does too, because it requires you to know all the right parameters to pass for it to do the right thing.

Exceptions

Exceptions are just bad. They are a separate, hidden control flow that you constantly need to be wary of.
The name itself is a misnomer in my opinion, because they're rarely exceptional: errors are not just common, but an integral part of software development, and they should be treated as such.
Errors as values are much clearer, because they explicitly show that a function may return an error and that it should be handled.

Classes, interfaces and polymorphism

I have lots of gripes with object orientation. Not everything needs to be an object, not everything needs to be polymorphic. There's no need to have a Base64Decoder, much less an IBase64Decoder or an AbstractBase64Decoder. Base64 only works one way, there are no alternative implementations, a function is enough.

I'm a lot more on the data oriented side of the isle than the OO one, but I digress.
Object orientation can be good in certain contexts, but it's not a silver bullet.

Encapsulation for the sake of it

Let's say you have something like this:

class Point {
	public float X, Y;
}

With the Clean Code approach, it magically becomes:

class Point {
	private float x, y;
	
	public float get_x() {
		return this.x;
	}
	public float get_y() {
		return this.y;
	}
	public void set_x(float x) {
		this.x = x;
	}
	public void set_y(float y) {
		this.y = y;
	}
}

Why? Who the hell knows. It makes absolutely no tangible difference, it only makes your code longer and more verbose. Now, if a value needs validation, sure, but oftentimes this is just done regardless and it drives me insane.

Abstract classes for everything!

• "You'll never know when you'll need to add another implementation, right?"
• "You don't need to know the underlying implementation"

The problem with wanting to create the most generalized code in advance is that you end up stuck in abstraction hell.
You may as well not need the ability to have arbitrary implementations, but now you need to plan for that.

Not only that, but it also makes reasoning about your code harder: how many times have you had to step through your code just to figure out what was being executed | just to figure out what particular concrete class was hiding behind an abstract class reference?
I myself, way too many, and there was often no reason for that.

Also, the idea that you shouldn't know about the implementation is crazy to me. Completely encapsulating data and behaviour not only makes you miss out on important optimizations, but often leads to code bloat.

There's more but I'm tired of typing :)

Take a look at these if you want more info or someone else's view on the matter, I wholeheartedly recommend both:

• It's probably time to stop recommending Clean Code
• "Clean" Code, Horrible Performance

The consultancy I used to work for in the late 90s would have crucified any developer that didn't write "a data abstraction layer that allows you to pop off the original db and substitute a different one later".

How many times in my 25 year career have I swapped out the database (and been thankful for such an abstraction layer)? 0 times.

I generally agree with the idea that code should be as simple as it can be to accomplish the goal of the code… I just haven’t been convinced that Clean Code is the way to get there, necessarily. The book does contain some good advice , to be sure, but I wouldn’t call it universal by any means.

I also think TDD is a very optimistic strategy that just doesn’t match up with reality terribly often.

Actually, I think that’s what confuses me the most about all of Uncle Bob’s books. I’ve read a couple of them and thought, “All this sounds great but real world development just doesn’t seem to work that way.” Like, all of his advice is for best case scenarios that I certainly haven’t encountered in my career.

I say confusing, because surely he’s been in the profession long enough to have seen the disconnect between what he’s preaching and real life, right???

Here's the Wikipedia page

Basically he is an old man/ software engineer who's famous for his philosophy of coding.

cleanerer code. gotta leave room for a fourth book: clean code and the crystal skull

The problem is that a lot of people don't understand when to ignore the rules and just stick with them forever.

We had a developer once that always said KISS KISS KISS whenever we pointed out that her functions are working but not reusable, so she wrote 20 functions that all did the same thing, but with slightly different parameters. And that's just one of the examples