The use case that comes to mind first is 'git bisect'. I love that feature, but I also love to leave a messy trail of commits in my history. In other words, I expect that there will be commits in my history where a full test run might not work, or maybe even things might not compile.
Of course, that sort of thing royally messes with 'git bisect'.
If git had a primary concept of "here's a synchronization point", then it'd be much easier to build tools like 'git bisect' (and even 'git log' etc.) around those sorts of paradigms. That'd offer the best of both worlds -- rich, detailed history showing how something got done, but also points at which it was believed that all was good in the world.
A push is (should be?) a natural synchronization point, for example.
Some form of nested commit would be useful for this I suppose - it would be arranged with something like an interactive rebase, that would squash a sequence of commits into one (for the purposes of log and bisect and the like), while leaving the original ones still accessible. This would give you your neat history for most purposes without losing the original commit comments and original sets of individual changes.
This is of course a bit like how branches are merged together ordinarily, at least if you don't go around deleting them the moment you're done with them. And sure enough it looks like you can sort of persuade git bisect to treat ordinary branch merges like this:
