We are talking about state here. In my opinion if you have business data that needs to be persisted you should be using a SQL database. I also think that you should design and manage this outside of an application context. I.e use SQL scripts for DDL and migrations.
The business data is likely to outlive your application by a big margin. Having this completely separate from the app will make it much easier to maintain in the long run. Perhaps after 5 years you want to use a completely different framework. Your business data though is still the same and by having it managed outside of the application makes this transition much easier. You can also add multiple different applications to your data without having the design choices of one framework affect any other.
On the other hand. If the data is only there to help run the application and not a thing in itself then the database-less approach is interesting. This auxiliary data can be stored in many different ways and can be quite tightly coupled with your application as it is more there to help the application than being data you care about in the long run.
A third type of data would be ephemeral data which can be recreated at any time. This is usually stored in memory can can be recreated when needed.
Likely your application will contain all three and there may some overlap between the three. What I think is important is that business data and the auxiliary data is loosely coupled. On is the core of your business and the other is just there to help.
