Every makefile I've used in the last decade has had every target marked as phony. When you're disabling one of the primary features of a tool to continue using it because you know how to use it, it's time to find a new tool.
Explicit is better than implicit? If everything was implicitly PHONY then of course people would complain about that as well. This is a bit like typing in function-signatures. But what's the proposal here, acknowledgement that your use-case is the best / most normal for default behaviour? Should function sigs that are missing type-hints always default to strings because that works well with your project code?
It's not about being explicit it's about using an abstraction that doesn't fit what you're abstracting.
Make operates on the abstraction of targets are files. If you don't confirm to that abstraction, make is the wrong tool. To use the hammer analogy, just because you're good at hammering something, doesn't mean you should use it for a screw.
Tools like docker and terraform don't use conventional files for state. Running tests in e.g. golang doesn't generate output files. Logging into the GitHub cli or aws don't have input and output files to compare for whether the task needs to be re-run.
That's a fair point. Funnily enough, I have the same complaints about terraform - the out of the box defaults (local state/lock files, and how backends work) are nonsense and incompatible with how the tool is actually used.
Make is not a task runner. Let me quote from it's manpage:
The purpose of the make utility is to determine automatically which pieces of a large program need to be recompiled, and issue the commands to recompile them.
And yet of course it runs tasks all the time in thousands of projects for decades, so there's the possibility that you're being overly literal and pedantic about the whole thing. Make specifies DAGs and helps resolve paths in them. A build is just a "program" where "recompile" is "re-execute task" and dealing with file-based dependencies is a special case.