Interesting article! I think this is the first time when I hear something (more or less) against MediatR, so I am happy that not everyone thinks this is a "silver bullet" or the "new dot net standard way of doing things".
I am also a fan of it, but, I do not consider it should be added everywhere, either.
To play a little bit as the devil's advocate, let's clarify a few things:
1. CQRS (command and query responsibility segregation) is something different than CQS (command query separation);
2. MediatR wasn't created to solve CQRS "problem", it was created to implement vertical slicing and CQS. This is why you can add pipeline behaviours and so on.
Of course, you can use it in the case of CQRS, event sourcing and so on, but this wasn't why it was created in the first place; (in the end you can implement strategy pattern even if you have only an if with an else).
3. The answer "Because it's cleaner, it abstracts the business logic", feels off for me. I think those people do not really know what MediatR is all about, or they don't care. I also know people that add a lot of packages even if they don't use them to their full potential, only because they are afraid of not "reinventing the wheel". This doesn't mean that they are correct, or we should all do that because they said so.
4. You shouldn't always separate reads and writes, but separating the flows in vertical slices, brings advantages, most of the time (but of course, we shouldn't create a rule out of it), and if you want to do only this, we shouldn't add MediatR, for such a simple thing, that could be done with a few interfaces. To be honest, I find it easier to maintain, understand and test, so I don't fully agree with you in this direction.
Everyone has a different understanding of what "clean code" means, and you'll never make everyone happy.
To use or not to use mediatR, you'll always get the classic answer: "it depends". Even in your case with the validation, you can create a validation pipeline that validates the "shape" of the data, and use fluent validation or whatever, to validate the "business rules", as domain validation. In this case, you won't have double validation.
There is not a right and a wrong and we will always be a little subjective, even if we like to say it or not.
