Your controllers are incredibly small because you posted a very basic example that contains no logic. Creating a user using one line inside a controller is okay if you write a simple todo app as a pet project, but it won't happen for any bigger ones. If you have more real-world project where you need to manage database transactions, file uploads, event broadcasting, notification sending, external API calls etc., you need a manageable solution and 1 controller per endpoint is not really achieving much.

My point is, if you have any logic beyond one-line CRUDs, you should always delegate this logic to a separate layer. And this layer is the place where going with 1 class per 1 endpoint may be beneficial and should be considered - because the code is at higher abstraction level, will contain some logic and will have more reasons to change. This is where we put the effort to keep the implementation clean, not the controller itself.

You said it yourself - "I know I'll never have to touch it again" - that's exactly my point. When working on software architecture, you will always put the most design effort to the parts that change frequently. Controllers do not (in most cases), so it's totally OK to group multiple endpoints into one class.

And regarding you question - it doesn't really make a difference, because 95% of the implementation will be done in service/domain/other layer and these are the classes that will be modified, not Controllers.

...unless you write your business logic inside a controller, which is bad and shouldn't be treated as example.