> I'm sorry, but super no. No game designer has ever feared that they would end up with a good toy, or a great activity, rather than making bank on Steam.
If you want to make Minecraft, make Minecraft. If you want to make Doom, make Doom. These categories are not about validating or condemning either experience.
The point of the categorization isn't to say, "I can't do this because I would be making a toy instead of a game." The point is to say, "I want to make a game/toy, and because of that, I know that there are certain design heuristics that I need to pay attention to."
> The only rule Minecraft broke is the one that says you can't code a financially viable game in Java.
And the lack of permadeath for most players, and the general lack of resource scarcity, and the lack of difficulty increase as gameplay progresses, and the lack of a narrative justification for the world, and the lack of a single clear goal (ascend), and the lack of any kind of scoring system, and the blurring between cosmetic and gameplay rewards, and a bunch of other things.
Minecraft is brilliant. And if Notch had sat down and looked at Rogue and said, "this is where I'll get my design ideas", then Minecraft wouldn't have been brilliant. It's a fundamentally different experience than something like Rogue, or even Rogue-lites in the vein of Enter the Gungeon. It's fundamentally different even from other crafting/building games like Terraria, which have much more traditional game-elements like difficulty curves and general progression systems.
It doesn't really matter whether or not you want to call Minecraft a game. But it is useful to look at a game like Minecraft and to be able to say, "yes, I know that Minecraft decouples resource rarity from resource value, but that's because Minecraft is doing something different than other games, and in most games that would be a bad idea."
Game design is about filtering ideas. There are an infinite number of things a game can do, so a tool that lets us zero in on which ideas are likely to be good or are likely to be bad is extremely valuable.
You're right that the mark of a great designer is not in religiously sticking to a certain category. However, it often is the mark of a great designer that when presented with 7 or 8 ideas, they can quickly pick out, "this idea is worth implementing, and this one isn't". Categorizations help with that.
I have seen many designers look at very outside-the-box games like Minecraft or Animal Crossing and say, "well, I can reuse any design decision from those games." But the only reason those atypical design decisions work in those games is because they are atypical games that commit to a consistent philosophy. Understanding the core of that philosophy is what allows a designer to intuit whether or not two design decisions work together.
Making a good toy or great activity is awesome. But if you make a weird hybrid between a game and a toy with discordant design elements that contradict each other, that's just a bad experience in general, no matter what you want to call it. Categories allow us to group design elements that work well together and exclude design elements that are discordant. Understanding common categories allows us to predict when we might be falling into the trap of including discordant mechanics in our games.