... so have a policy of all your "checkpoint" commits just having "checkpoint" as a message. Or ".".
Forcing a commit message is a good default, because it's a good idea to nudge developers towards properly expressing what they're doing. But if you think you know what you're doing, it's easy enough to work around.
Checkpointing is generally different from commits in more than just not having a commit message (ex: should one allow checkpoints to be pushed? should they be suppressed in the log by default? should they be part of the normal revision graph or a separate hierarchy?).
Yes, you can emulate them because Git is a general versioned, hierarchical key value store. But by the same token, you don't really need Git, you could just store each new version in a separate directory. A version control system is about more than providing raw access to a storage engine; it needs to support appropriate high-level operation and integration with the development process.
The problem here is the Procrustean way in which people try to force everything to fit Git's model rather than to think beyond its limitations (many of which are shared by other VCSes, I don't want to single Git out here) and to address these problems at the user experience level (especially when we're talking about normal users, such as writers and artists, who may not have a deep understanding of the technical details).
Forcing a commit message is a good default, because it's a good idea to nudge developers towards properly expressing what they're doing. But if you think you know what you're doing, it's easy enough to work around.