you're defending Doctrine as a more scalable paradigm for large monolithic apps

No, I'm defending Doctrine as an effective tool for OLTP applications. Yes, OLTP is about small and self-contained interactions per intent, and you can still use the ORM where needed, or avoid it when it doesn't fit.

Every micro service owns its own tables and no one else has access to them.

This sounds even worse than having a monolithic app, to be honest. While it is feasible in theory, each of those micro-services would have to ensure to be able to work only with one aggregate, and cross-aggregate transactional interactions become very tricky.

Not to mention that you added "micro-services" to it, which already adds up for "hype" vs "working solution".

Also, I don't understand your InvoiceRepository example. The domain should expose less granular API calls that match the domain. I.e. API modeled after use cases, not some abstract domain model. I doubt the secretary wants to know the intricacies of Doctrine's model either.

Good point: I didn't actually take the time and think about a better example. Take Invoice::createFromData($inputData, $invoiceRepository) and then a Invoicing#sendInvoicesForTheMonth($month).

Coding this logic in an OOP fashion is nice and simple, but iterative and inefficient. Coding this low-level is efficient but completely unmaintainable. Engineering is just about trade-offs: my point is that bashing the tool before finding out whether you need one or the other approach is just useless. You can plug in the tool when you prototype, and then hardcode all your SQL logic once your E2E tests are in place.

now that you have this cache, you can tell naysayers "ah yes it's slow in benchmarks but you didn't enable the cache"

Nope, my default response to naysayers is "you're using the tool without knowing how to use it".

I'm currently dealing with a large project having this sort of issue, and that because developers didn't study the tool before going on and using it in the most useless way (CRUD, in this case, not even OLTP). No, caching won't save them, and they'd have the same kind of trouble if they went with TableDataGateway or ActiveRecord :-)

The ORM can't take architectural decisions for you: if you bash a tool for architectural decisions, then I might as well just tell you that using a tool is an architectural decision.

More on this at http://ocramius.github.io/brnophp-2014-slides/