I would posit that it's easier to maintain the views and procs on a large system where the calls are explicitly made from the component in question then having to root through the ORM and abstractions to figure out what needs to be modified for a front end change.

I have maintained databases with 200-300 tables and roughly a 1000-1200 procs for a massive online E-Commerce site. Though, admittedly, we had about 4 views and the majority of the work was concentrated into around 100 procs (or so, I never did finish my accounting on that). The rest were for EOY reports or taxes, one shot procs for delivering the un-mailed invoices to the mailing room, stuff like that. Once an hour kind of items, at most.

Naming conventions, intelligent Schema usage for module identification, and communication between the front and back end of the code for determination of usage keep that maintenance from being a nightmare. You do have to bring your brain to work every day though. It can be easy to trip. I can't see a sufficiently large front end being any better, though, ORM or not.