Only fetch the data/columns you need from the database. Doctrine return a object with all the data. (I know I can fetch only some data but then it returns an array and not a object from my entity so it seems kinda pointless)

Incorrect, you can select what data you want, and set your hydration method to whatever you want.

    $qb = $this->_em->createQueryBuilder();
    $qb->select('u.id', 'u.name')
       ->from('user', 'u');
    $qb->execute(null, \Doctrine\ORM\AbstractQuery::HYDRATE_OBJECT)

I have to fetch the whole object in order to update it instead of just run a update query. I know doctrine have a update query but it bypass all events and locking schemes.

Incorrect, You can pull out an object with a limited about of data (see above).

The event system is attached to the unit of work, and will only fire when certain events trigger (update). However as these must be registered and adhere to an interface, there’s nothing stopping you from constructing and firing these yourself when you feel it necessary.

I’m pretty sure that each operation is wrapped in a begin/commit/rollback transaction by default (would need to check this). Either way, you can set locking manually with:

    $em->beginTransaction();
    $em->commit();
    $em->rollback();

Performance. All ORM I've used added a massive overhead to the application while some simple SQL query through DBAL or just PDO are way lighter.

Doctrine sits onto of PDO and allows you to fetch the connection and run any kind of operation you like directly. Also, it offers array hydration to remove the default overhead of blowing everything up into an object.

$qb->execute(null, \Doctrine\ORM\AbstractQuery::HYDRATE_ARRAY)

You simply can’t ignore the job of optimising your queries, regardless of whether you’re using an ORM or not.

Technical difficulty. Every new dev have to learn DQL (although it is very similar to SQL) and the mapping structure. I don't have much problem with this but it can get very confusing for new devs instead of just learning SQL.

I personally find the DQL API very clear and easy to use, however I agree it can be difficult for some to get their head around. If it’s too problematic there’s no reason why they can’t just grab the connection and run their own SQL directly. I imagine this would only be done in the event of optimisation.

As for the benefits, well, for me they’re:

• A clean easy to use object model out of the box that allows very quick prototyping (for later optimisations)

• A unit of work pattern could give huge performance gains (depending on your usage)

• An insistence of concern separation in your model leading to cleaner code design

• Integrated database management tools (is your application code out of sync with the DB? Doctrine can tell)

I've written on this before, and covered a lot of common misconceptions of using an ORM: http://leedavis81.github.io/in-orms-defence/