I will grant that "don't use NoSQL" isn't the correct advice in absolutely all cases. Once in a blue moon there is a case where it's the best solution, and if you say you have one of those cases, fair enough, I'll take your word for it.
But the vast majority of people who use NoSQL should be using a relational database instead. And the consequences of using NoSQL where you shouldn't, can be very bad indeed. (If your data gets messed up, it's not like a bug that can be put right just by fixing your code.)
So I will stand by "don't use NoSQL" as general advice. If you're really sure you know what you're doing, if you have sufficient expertise on databases and understanding of the present and future characteristics of your workload to be certain you're an exception, fine; but then you don't need general advice in the first place.
I will grant that "don't use NoSQL" isn't the correct advice in absolutely all cases. Once in a blue moon there is a case where it's the best solution, and if you say you have one of those cases, fair enough, I'll take your word for it.
But the vast majority of people who use NoSQL should be using a relational database instead. And the consequences of using NoSQL where you shouldn't, can be very bad indeed. (If your data gets messed up, it's not like a bug that can be put right just by fixing your code.)
So I will stand by "don't use NoSQL" as general advice. If you're really sure you know what you're doing, if you have sufficient expertise on databases and understanding of the present and future characteristics of your workload to be certain you're an exception, fine; but then you don't need general advice in the first place.