Well, for use-cases where an SQL database works well, I would recommend using an SQL database. NoSQL generally tries to provide a better alternative for the use-cases where SQL is suboptimal.

For example, I'm currently building a build system with caching. I need the cache to be persistent on disk between builds, but I just load the cache into memory on startup and if I have a breaking change in the format, I can just wipe the whole cache. So, all the strengths of SQL are irrelevant and the pain points are still there. I mean, truth be told, I'm not using an actual NoSQL DB, but rather just writing a JSON file to disk, but it's still similar.

Another example is that at $DAYJOB, our last project involved making lots of recordings and training a machine learning model on that. The recordings had to be created early on, long before our software was stable and the data scientists who would work with that data, would write all kinds of transformation scripts anyways. In that case, again, I do not think an SQL database would've been the best choice, because we needed the flexibility to just push data into a heap and then later clean it up. If an older format would've really become unusable, we could've just left that data behind, rather than trying to constantly update all the data to the newest database schema.