There are many good reasons for choosing an ORM tool instead of using stored procedures. But one reason has always struck me as rather silly. That is choosing an ORM so that you can easily switch databases in the future. I am not disputing that using an ORM enables you more in changing databases, but I am questioning why you would want to base your project on such an assumption.
There are several problems with the idea that you would want to change databases in the future. One is that in a non-trivial application, your interaction with the database is not limited to running SQL queries against it. Most mainstream database servers have several features that enable you to gain better performance and scale your application better. And you would be well advised to use such performance tuning.
If you decide to switch to another database server, you will have to do similar activities in the new server. You would have to relearn how to do it in the new server, or hire resources who are knowledgeable in it. There is also the possibility that some data migration efforts may be required, even though tools do exist. It is not as simple as you may think and is more a distraction than a benefit to the project.
In terms of price and scalability, most database vendors also offer you an easy path upwards. You can run the lowest version on your desktop and it probably costs $0. And there would be a high-end version that scales to multiple machines and costs thousands of dollars. So the need to rewrite the software for another database server is reduced.
Now, I have seen instances where a rewrite from Oracle to mySQL (for cost reasons) or from Access to SQL Server (for scalability) or from some dead database vendor’s database to a database in the present market has been done. But these were projects where there was no ORM to begin with. If somebody started a project in recent times and then had to change their database server, I wonder what thinking they put into selecting the database in the first place.
Just as you would not choose your programming technology in a casual manner, it is important to put sufficient effort in choosing the right database server. Being cavalier about it and assuming you can easily shift database servers (and would want to) in the future is not the right way to go.