well yes and no :) .... sql will increase the time-complexity of document based relation systems. "custom forms" for example which now have to be stored in "deep table"-structures and my favorite edgecases -> filter systems with "having sum/count" in deep tables to find if a user has a username and a password but no email address ;D.
The next thing is location/data based sharding has to be implemented yourself -> in SQL you need one block device (usually 1 HD / partition) and every transaction is considered done if the HD gives you the write ACK.
If you consider all those details for the decision I agree you can stick with SQL because SQL has the CA of CAP but it misses the P so for network partitioning you have to think of a queue/buffer to compensate for that.
Anyhow :) I always try to pick things based on the datastructure :) so if I have a document storage and I basically never change those documents, I probably don't really care about consistency and everything that has to be consistent is in the SQL-Database anyway :)
But I encourage critical thinking :D just don't go dogmatic on it :) you probably always trade time- with space-complexity or CAP and you only get 2 out of three :)