Invoices seem like a pretty good candidate for a document DB to me. It's much, much easier to store a list of "line items" in a single document than it is to extract those out into a properly normalized structure. What advantage does having that data across multiple tables give you?
Blog comments, on the other hand, might benefit from more normalization. Cramming a bunch of comments into a post document could result in contention problems, depending on the engine and how you're handling them. In CouchDB, you'd end up having to update the entire post document for each new/changed comment. Mongo handles it better, since you can atomically push new comments into your doc. Still, I think I'd rather have them in their own documents on a busy site.
The Key benefit of Relational Databases is to maintain integrity. And they do this primarily via 2 concepts: (1) Normalization: storing each fact in the db once (2) Referential Integrity.
In an Invoices you have an Invoice Header, that should refer to multiple entities, buyer, seller, shipment address etc ... . Invoice detail that refer to the Header and represent a one to many relation between the data in the invoice header and the items in the invoice. Which may also have additional relationship attributes, like price, discount or any details specific to the item, for example, maybe your DB support a shipment address per item!
Anyway, in a relation DB an invoice refer to many entities (separate facts) and many relations (also separate facts) each worthy of its own table that refer to each other.
If you believe that Invoices are a good candidate for a document DB, you probably don't believe that the Relational Model is valid in general. Or that the 2 concepts I mentioned at first really help integrity!
The main flaw I see is that the relational model makes is hard to create dynamic models. A good Relational Model practice is that an entity in a Relational DB should represent an entity from your Universe Of Discourse (uod). That is the say, a model is better when tables represent real entities of the problem you are modelling! This is sometimes impossible when you want to store dynamic structures, some argue that this is not the fault of the Relational Model theory, but rather its implementations.
No offense, but putting critical financial data like invoices into a schema-less datastore strikes me as short-sighted and risky in the extreme. Best case, you're making a bunch of extra work for your accountant; worst case, you could completely fail to impose the structure needed to do basic reporting and billing. Financial data is highly structured already; I'm not sure why you'd throw away all that nice regularity and structure in order to save a few inner queries.
Also, in the case of a simple blog app, I don't think that contention is going to be your biggest worry. The on-disk structures for CouchDB are append-only, so your biggest worry isn't going to be locking, it's going to be the stale document revisions taking up disk space between vacuum operations, and the replication overhead for all the intermediate versions.
Blog comments, on the other hand, might benefit from more normalization. Cramming a bunch of comments into a post document could result in contention problems, depending on the engine and how you're handling them. In CouchDB, you'd end up having to update the entire post document for each new/changed comment. Mongo handles it better, since you can atomically push new comments into your doc. Still, I think I'd rather have them in their own documents on a busy site.