Why not go about this more axiomatically? For example, why is "CMS/blogging" better suited to document databases (or whatever)? What are the common properties of these applications that make you think they're better suited to one or another technology?
Consider the strengths of each DBMS technology and, indeed, the theory each one is based on. What data model do they implement? (Does each one in fact have a data model?) What are the properties of each data model, and how do the properties of the application map onto those of the data model? If you develop such a map, you'll have a way of characterizing any application, even one you've never heard of or one that hasn't been invented yet.
Codd defined a data model as comprising three interlocking features: structure, operations, and constraints. The relational model has all three in spades. If you look closely at the alternatives, you'll find they're missing at least one and usually two of those. Any technology not based on the relational model is ipso facto less functional. For that reason it's safe to say every application can be supported the the relational model (if not by extant relational products). The relational model is still more fully developed, more powerful, and yet simpler than any other yet devised. It will be hard to improve on because it rests on predicate logic and set theory.
Perhaps you can identify applications for which, say, well defined operations don't matter. But you want to be very sure you first understand why they matter in general before you can say with any certainty why they're not necessary (or even just useful) for a particular application.
Sooner or later, someone will tell you "relational doesn't scale" and that technology X is fast. When they do, remember that they've implicitly given up features that technology X lacks relative to the relational model, features that might well matter. Besides, a data model isn't fast or slow, only an implementation is. Whenever there are more programmers than machines, it's cheaper to buy faster hardware than to hire more programmers.