It is definitely not the answer to most common real-world full-business data requirements. BUT it is certainly a candidate for some niche problems where either a full RDBMS is overkill or where an RDBMS's complexity is not required and sits actually in the way of performance/scale (wouldn't want to run Google's search engine on a MS-SQL platform).

Where an RDBMS is merely overkill, you could look at whether the maintenance-overhead to support 3 platforms (document file-system, relational transaction data AND one or more NoSQL databases) instead of 2 (the documents with relational database) is worth it (yes, the business WILL still need an RDBMS for many business-processes). Or whether it's just easier to add the additional database(s) into the already existing (and maintained/supported) RDBMS.

For those niche problems NoSQL will bring a lower-cost solution than scaling up/out of an existing RDBMS, and so by all means use it.

If traditional RDBMS and NoSQL platforms can be seamlessly integrated into a single platform and the strengths of each applied to the appropriate problems without adding maintenance/cost overheads over a one or the other solution I might look into NoSQL in my field (mostly automating/integrating complex business processes).

Although: I'm still waiting for seamless integration of a document file-system with the transactional database, although I might be out of a job when off-the-shelf solutions would become that easy.

Yes, I know that NoSQL could provide an interesting alternative for file-shares for document-storage, but it would still require maintenance/integration of 2 platforms without much benefit over the current 2 platform solutions, but that may change in the not-so-distant future, so I'll keep taps on this new technology.