I agree, ORM:s work best when the database is designed for the one chosen and most queries are fairly simple. There are usually ways to cram out decent performance also with complex or long running queries, if nothing else one can write the SQL by hand. For stored procedures I would probably write application modules that handle them separately, using the PDO or whatever connection directly in them and pass around such objects in application code where needed, or just rely on triggers or hooks in the database engine if that’s a viable way to run the stored procedures.
In my opinion it is the job of the developer to know these things and choose tools and libraries appropriately, and one has failed in that role if one has to go to the DBA and ask why the application is slow or stuttering in production rather than have a conversation about different alternatives regarding schema, indexing and optimisations. It’s commonly trivial to dump generated SQL and look at whether it uses the correct indices, has a reasonable complexity for the schema and so on, so one should know this when knocking on the DBA door and asking for help.
For a use case with thousands of requests per second I’m not so sure I would choose PHP, even with some help from opcache, FPM and whatnot it is kind of hard to keep a non-trivial application stable under such load. The JVM might be a better choice, unless the PHP project has matured in this regard since 7.1 and 7.2, which I’ve seen choke on bursts of 3-500 requests per second even though DB operations were simple CRUD and the code pretty straightforward as well.
As for choosing an ORM, I prefer Doctrine over Eloquent, I find it easier to keep business logic and database access separate, and CLI tools easier to implement compared to Eloquent. Either way, Slim makes it easy to use either or roll your own solution, especially when combined with one of the richer container libraries, like PHP-DI.