1) Generally speaking the overhead of running a full RDBMS is too great and it would be adding needless load to the system and complexity.
Having one installed makes your life easier as a developer but makes the life of the owner of the machine worse as their machine is likely to run slower and with more issues. In developer vs. user confrontations the user should almost always win.
2) Many data stores have specific needs which are not met by something like SQL Server Express.
For instance, error logs should be written to the simplest possible thing to maximise the chance that the write will happen and the data will be available. SQL Server is never going to be that simple.
For more complex applications the argument tends to be more around optimising for very specific user cases - flat files can be lightning fast.
Stored procedures are bad, they're often slow and approximately as efficient as ordinary client side code.
[The speedup is usually due to the way the client and stored procedure interface is designed and the way transactions are written as short, focused bursts of SQL.]
Stored procedures are one of the worst places to put code. It breaks your application into two languages and platforms according to rules that are often random.
[This question will be downvoted to have a score of about -30 because many, many people feel that stored procedures have magical powers and must be used in spite of the problems they cause.]
Moving all the stored procedure code to the client will make things much easier for everyone.
You'll still have to update the schema and ORM model from time to time. However, schema changes are isolated from ORM changes, allowing some independence between applications and database schema.
You will be able to test, fix, maintain, understand and adapt all those stored procedures as you rewrite them. Your app will run about the same and become much less fragile because you're no longer breaking into two different technologies.
ORM's are not magic, and good database design skills are absolutely essential to making it work.
Also, programs with a lot of client SQL can become slow because of poor thinking about transaction boundaries. One of the reasons stored procedures appear to be fast is that stored procedures force very, very careful design of transactions.
ORM's don't magically force careful transaction design. Transaction design still has to be done just as carefully as it was when writing stored procedures.
Best Answer
Using the approach of requiring 100% of the database interaction to be done through stored procedures is actually a bad idea, I would say. The database should be for storing "data" (among the usual CRUD functionality and ACID properties), not for storing procedures to encapsulate the entire database. A few reasons why this is a bad idea include:
However, you should also consider how "likely" or not that the above things may happen during the lifecycle of your project when making your decision.