Admittedly I'm not a veteran software developer, but I thought a lot about this subject in recent months, and the following are my observations and conclusions.
You're quite right to think that CQRS is more involved than prefixing some MediatR-consumed classes as 'commands', and others as 'queries'.
Unfortunately, for some reason I don't understand, people started to equate MediatR with CQRS recently, even though Jimmy Bogard usually talks about MediatR in the context of vertical slice architecture.
Vertical slicing
The general benefits come from the fact that you're creating vertical slices instead of using a traditional, layered, service-heavy approach. This decouples the use cases from each other, decreasing the amount of bugs and complications that originate from problematic implicit dependencies between the various operations due to their shared services.
This is a basic pattern you can implement in simple applications without much friction, and arguably provides consistent benefits everywhere.
CQRS
On the other hand, what CQRS entails is creating a parallel data access structure for queries and commands, plus optionally creating parallel models as well. This inherently adds to the complexity and overhead, and in general, simpler systems it provides...
No performance benefit, since you don't have to scale reads and writes independently.
No structural benefit, since you don't need e.g. two separate dev teams working independently on the read model and write model.
The only benefit that would apply is that it's easier to reason about the operations because they are individually encapsulated, a.k.a. command pattern. But you already got that benefit from using vertical slicing alone.
(I honestly believe that MediatR should have been called CommandR. It implements the command pattern, not the mediator pattern.)
So, what you should ask yourself is what sort of advantage can you derive currently in your specific use case by committing to that added complexity and overhead.
Key points:
CQRS isn't a fundamental, universal concern in software architecture, like e.g. SOLID and (arguably) vertical slicing is.
If the advantage is not evident, the majority of experienced developers who looked at that codebase would see the CQRS aspect of it as a distraction from code quality, and a bloat.
When using vertical slicing and MediatR, it's easy to implement CQRS concerns just when they are actually needed. This further decreases the justification for adding that plus complexity in a prima facie manner.
So, what I would personally suggest is to:
Keep using the same repository for commands and queries, let go of the idea that you're doing 'CQRS', but as a semantic detail keep calling those IRequest classes as 'command' and 'query'.
When you encounter a situation where you see that queries on a given entity would need to be scaled independently for the load you're facing, you'd want to use a separate db, or Dapper instead of EF Core, and/or a different model, THEN implement the parallel CQRS structures for that part of your system. And, as you grow your project, extend the CQRS structures strictly as needed.
Of course if you simply want to create a sample project to explore CQRS, then go ahead and implement whatever would be useful for your learning experience.
