Suppose there is a method with a long switch statement. You want to change what happens inside a case clause. All you have to do is open the class and modify the logic inside the case clause. No other case clauses are affected. If you want to add an additional case, you simply append to the switch statement. I don't see what else is affected.
It's likely unintentional but you're cherrypicking your problem to fit with your argument.
Consider the scenario where every case logs a certain message (different messages for different cases), but because you haven't separated your concerns, that logging action explicitly appends it to a file on disk. In other words, every switch case looks like this:
case "anothercase":
DoThisSpecificThing();
DoTheOtherSpecificThing();
File.AppendLine("Doing the specific and other specific things");
And you have many of these cases. Now, you decide that as part of your logging, you want every log line to start with a timestamp. Or, alternatively, you want to change your logging from being file-based to a console output, or storing it in a database.
You will have to change every case in order for that change to take effect, and if you forget one case, not just across your switch but across your codebase; you will have fragmented your logging approach and it won't be consistent.
If instead you had created a logger class which separated the logging concern into a separate class on its own; then this would not have been an issue. You only would have needed to change the logger's logic. Every consumer (e.g. the cases in your switch) would only be doing something along the lines of:
case "anothercase":
DoThisSpecificThing();
DoTheOtherSpecificThing();
myLogger.Log("Doing the specific and other specific things");
Changing the internal logic of myLogger.Log (e.g. having it prepend a timestamp, or store the message elsewhere) does not require you to make any changes to the code that calls myLogger.Log. Regardless how many switch cases you have (in this file, or in your codebase), you are able to alter the logging behavior by only needing to alter the logger.
That benefit is one you can only achieve if you pre-emptively identified that logging is a separate concern and therefore should be separated into its own class. If you build it without separation in mind, then you will struggle once you realize that you have to make changes to this concern that is now littered across your codebase.
If you're on board with the above, then your subsequent question will likely be where we draw the line of what should and what shouldn't be a separate concern and if we should apply this process infinitely precisely.
Yes, there is such a thing as too much separation where it creates effort/complexity instead of resolving it.
No, this can't be easily answered. There is no universal deterministic measure of precisely how granular a responsibility/concern should be. This is a subjective and contextual assessment made by an experienced developer, not a rule that you can write down and expect any developer (even if a newcomer) to blindly follow and execute perfectly.
No, the lack of a universal rule is not an argument that we shouldn't bother with this separation of concerns. The value of separating your concerns is clear. Even if reasonable people can disagree on exactly where to draw that line, the overwhelming consensus is that there is such a line that we should be mindful of.
