The idea of "just dumping JavaScript objects in there" is one of the very pitfalls of the technology.
I also regularly used NoSQL (Mongo, Firebase) on the premise that I was prototyping and it was faster. I thus built an enterprise app which has grown within a large company, and there's barely a day I don't feel insecure about the NoSQL db powering it, because the underlying data model is actually relational.
What field did I use as a "foreign key"? Are these "foreign keys" which are replicated in several places in sync? Will a change in one of these fields break the entire application? What is even the schema, and how do I "migrate" it as requirements change?
These are all questions which I now ask myself regularly when maintaining and extending the app, and which clearly hinder my development speed. The data model is not even that complex - around four main entities - but on the other hand the application code has grown significantly, and the effects of technical debt are thus compounding.
So, in a nutshell, any speed I gained at the beginning was undone later on.
And in line with your reflection, we often conflate the dev speed of NoSQL with an inherent property of the technology, when in fact what's happening is that we're simply more familiar with it. I'm all for "build in what you know", but if you want to build anything semi-serious, you should probably know SQL.
Granted that SQL forces you to think more deeply about your abstract data model ahead of time and how that materializes into a concrete schema. But I don't think one should ever shy away from this exercise, as it is a fixed time investment that will pay huge dividends down the line.
In other words: SQL is slower in that you have to devote some time planning and designing your data model at the beginning of the project. This may be five, twenty or a hundred hours depending on the complexity of what you're building. But this is largely a fixed investment which will dilute and make you faster over time, as operations on data thereafter actually become much easier and not harder. Other reasons why this is a worthwhile investment is because it can be quite fun, and because I believe it generally makes you a better application developer: data design should precede the implementation of logic, no matter what you're building.
> Don't get me wrong, I love MongoDB for a lot of weird stuff (like web scraping, CSV files, and archive data
PostgreSQL (and possibly other RDB technologies) allow you to dump JSON objects in the DB too - and in the case of Postgres this a mature API as far as I know. So you can opt for a mixed data model where the clearcut parts (eg, users and ownership) are relational, while others (eg, results of scraping, or other ever-shifting unstructured data) can be schemaless.
In summary: if your data is relational, go for a relational database technology, even for prototypes.