ORM's by and large do protect your from SQL injection attacks.

By using prepared statements, which you can use as well.

They don't. All decent ORMs have a layers architecture, and it's usually some "query builder/processor" or "DAL" or whatever that sits under/above the ORM your app uses (and can usually also be used directly, but has a horrible API since it's not optimized for this use case) that does the simple but tricky tasks of parameter sanitization and all...

The ORM is just an big fat thing that sits on top, and from which you only use 10% of the functionality it provides, but in theory each app uses a different 10% so it justifies itself...

ORMs can be ok... as long as you don't build business logic on top of and inseparable from it!

(As an example of horrible use of ORMs: some frameworks have ORM systems with an events system on top... god have mercy on your soul if you make the mistake of using this system to implement business logic, and end up with it accidentally depending on db connection and caching details, and not having time to refactor when you realize this! ...but if you avoid the trap, you can reap the benefits of the functionality that the ORM provides, while moving your logic at at a whole different layer of the app - hint: just invent a new "XBizLogicServices layer" or whatever and not import framework stuff into it if you can't find a better design, it will at least be easily testable.)

I wasn't defending ORM's.

I was just pointing out that if you use one you do receive protection from injection attacks. Just because only part of the ORM is actually performing the protection doesn't change the fact that you have it as a consequence of using the ORM.

You can also get the same protection by using a SQL library that supports prepared statements. But ORM's still provide that benefit.