There is rarely a case to use EF.
For example, you'll quickly realize you need to have ```AsNoTracking``` on your queries because the performance is terrible.
You'll also find that you can batch update/delete items.
I've also had problems with migrations after updating EF Core (don't remember exactly).
You can get spun up quickly, with Linq, using something like Dapper or ServiceStack.OrmLite. They work on raw ADO.NET, so they are incredibly easy to reason/work with. The errors that you'd run into wont be shrouded in layers/abstractions that are specific to EF/Core.
But I also think that heavier duty ORMs have their place. Recent circumstances have meant that I'm building out a lot of applications from start to finish in one to three weeks. These applications deal with very little data, the largest tables are in the 1000's of records and in circumstances like that I need crank developer productivity to 11 and for that I'm willing to sacrifice performance and simplicity. And for that EF has been a great companion.
I've also used a combination of EF and DACPAC. Where I used DACPAC to manage the schema and migrations and used EF for CRUD and that's been a pretty great combo. And I definitely have to drop down to sql, especially for reporting/analysis type queries.
My default is to just use ADO.NET with Dapper or ServiceStack.OrmLite.