I think the relationship is probably more about how those cavalier enough to abandon schemas are also cavalier enough to abandon transactional consistency!
Achieving each of these typically imposes some kind of development cost, and you can save that cost by simply discounting/ignoring the problem they solve in the first place.
To what extent those now-unsolved problems cause costs elsewhere, and whether those problem-costs exceed the saved solution-costs, is a question that is very specific to the application.
I also don't think they are always choosing availability over consistency. They are probably more often choosing perceived economy over consistency. I think it's just that with fewer consistency constraints, the system is naturally more available, and that then gets hyped-up as a feature, rather than admitting the real underlying logic which is "we save money on development by accepting certain classes of defect which others are not accustomed to accept"!
With SQL vs NoSQL, the trade-off is often more complicated than can be feasibly reasoned about.
SQL engines tend to be mature technologies which perform adequately for a variety of applications. Usually, the proposed alternatives can be seen to have some kind of advantage, except generality. That is, NoSQL technologies are heterogenous and far more specific in their area of application, and outside those areas they perform inadequately.
A company might get away with using SQL engines for all data stored under their roof, but they probably cannot get away with using one specific NoSQL technology for everything under their roof. Instead they end up with a menagerie of technologies, each with their own incompatibilities or incommensurate concepts, and each needing their own specialist zookeepers amongst the staff.
More often, I suspect the choice to use NoSQL technologies either comes down to perception of clear up-front costs of SQL engines, like licences, against benefits which are more difficult to quantify, or the use of one or the other comes down to the tastes and preferences of the developers and managers involved. I suspect there is rarely a fully-rational evaluation, because the question is simply too complicated to weigh, and that developers are not in fact "trading off" the merits of the two possibilities.
