Thanks for invite and sorry for the long post ...
Without knowing a lot about your projects it is hard to be specific. However if you are at the ideas stage and are looking to create MVPs then use the technologies you know and are most comfortable with - these can always change if the project(s) succeed. However, if you are working for an established company and have enough resources, know-how and time then you can go down the route of investigating the best long term solution - starting with some proofs of concept, for instance.
A key distinguishing feature between relational and current NoSQL products centers around the SQL Join. With relational databases the objective is to abstract objects into groups of very similar data (tables) avoiding data duplication as much as possible (normalisation) The objects are then re-constituted from 'related' data (hence relational) from the tables.
For instance, modelling a company, we could have tables for People, Roles, Departments, etc Roles will have a link to People, so we would have to 'join' Roles and People to find a list of people that occupy a role.
NoSQL systems approach things differently. The basic principle is that instead of breaking up objects to then re-constitute them using 'joins', why not just store all related data inside one structure and avoid the 'join' altogether ?
Most of the advantages and disadvantages stem from this difference in philosophy (approach) For instance, it is easy to shard NoSQL systems since the data for any one object is (there are exceptions) already in one place. Whereas can you imagine the technical difficulty involved in trying to 'sql join' tables that are spread accross several servers (possibly in different parts of the world) ?
ACID properties are often mentioned. Relationals provide ACID as a matter of course, but noSQL systems are evolving as well - for instance, MongoDB now provides ACID properties on a per document basis. Even so, using so called 'micro-arhitecture' approaches, this becomes less important.
As for querying, this shouldn't be a deciding factor as many NoSQL systems now provide their own querying language. The only problem I see is that there is currently no standard for NoSQL query languages. So if you chose CouchBase, you'd have to use their N1QL languages which is quite different from the querying language offered by MongoDB for instance.
Note: I have mentioned only document stores so far, but there are other types of NoSQL databases as well. Specifically, you may also want to consider wide column stores like Cassandra, key-values stores like Redis, etc It all depends on the data you are capturing and what you want to do with it.