(Almost) all applications benefit from ORM.

First, I don't agree with the advantages you list for ORM.

• Using ORM doesn't necessarily mean you don't need to know SQL. A knowledge of SQL will help understand what the ORM tool is actually doing, which is especially useful during debugging. Moreover, SQL may actually be required to develop complex queries that are beyond the capability of your chosen ORM.
• And as you say, portability is rarely a concern in real life.

Instead, the real benefits of ORM are:

• ORM saves programmer time because it saves writing tons of CRUD logic in SQL
• many ORMs include complex caching logic etc. that is difficult to write and debug. As well as saving time this can enhance reliability and maintainability of your application (or at least save you the time it would take you to achieve the same results)
• the best ORMs have a community of users who actively develop, maintain and support the product. The community around custom SQL is, at best, somewhat less focused on the problems we need to solve.

As you comment, one down side of ORM is a loss of performance. However, this can usually be offset by spending more hardware.

Typically, programmer time is more expensive that hardware, so ORM is genrally a good option instead of hand-coding SQL.

ORM is best for applciations with a lot of fairly simple CRUD database logic. ORM is less effective for:

• Applications that need little / no database access.
• Applications that are largely dependent on complex queries rather than simpler CRUD logic
• Situations where performance is critical, but where there is no possibility of deploying faster hardware

In my experience, these situations are rare. Hence my answer.

(Almost) all applications benefit from ORM.

First, I don't agree with the advantages you list for ORM.

• Using ORM doesn't necessarily mean you don't need to know SQL. A knowledge of SQL will help understand what the ORM tool is actually doing, which is especially useful during debugging. Moreover, SQL may actually be required to develop complex queries that are beyond the capability of your chosen ORM.
• And as you say, portability is rarely a concern in real life.

Instead, the real benefits of ORM are:

• ORM saves programmer time because it saves writing tons of CRUD logic in SQL
• many ORMs include complex caching logic etc. that is difficult to write and debug. As well as saving time this can enhance reliability and maintainability of your application (or at least save you the time it would take you to achieve the same results)
• the best ORMs have a community of users who actively develop, maintain and support the product. The community around custom SQL is, at best, somewhat less focused on the problems we need to solve.

As you comment, one down side of ORM is a loss of performance. However, this can usually be offset by spending more hardware.

Typically, programmer time is more expensive that hardware, so ORM is genrally a good option instead of hand-coding SQL.

ORM is best for applciations with a lot of fairly simple CRUD database logic. ORM is less effective for:

• Applications that need little / no database access.
• Applications that are largely dependent on complex queries and very little simple CRUD logic
• Situations where performance is critical, but where there is no possibility of deploying faster hardware

In my experience, these situations are rare. Hence my answer.