Enterprise Application Architecture - Is the OR framework worth?

Most of the Literature (http://www.martinfowler.com/books.html#eaa) describes following as the main architecture patterns for Domain Logic
Transaction Script
Domain Model
Table Module
Domain Model is considered to be the pure Object Oriented Design pattern
Most of the enterprise applications are data intensive and data retrieval (select query in SQL) will be very ineffective unless we use appropriate SQL query joining multiple tables with appropriate filter conditions. This is the compelling reason or using RDBMS for persisting enterprise data (along with transactional capabilities and data recovery).
If we use pure Object Oriented model (as described in most of the literature) we need to map one Entity per table (table in RDBMS). This will limit the usage of appropriate SQL queries for data retrieval.
One strategy adopted in many cases are bypassing Entities for data retrieval and using Entities only for Create, Update and Delete. Data retrieval will be directly from Service Layer (http://www.martinfowler.com/eaaCatalog/serviceLayer.html) through Data Source Layer (SQLDAO).
If we decide to adopt this strategy then Is it really worth using the Entity Layer for create, modify and delete? What are the advantages of using Entity layer?
In my option the main advantage of using Entity layer is elimination of SQL query writing for update by using some OR mapping frameworks. Writing SQL for update is complex. You may have a table with 50 columns and you have a screen where all 49 (excluding primary key) columns are editable and user may be modifying only one or two. Hence you need to dynamically generate the update statement based on the columns modified. If you are using a OR framework, framework will do this for you!
If you have small utility for SQL query generation based on the modified values (eg: http://ws.apache.org/jaxme/js/sql.html#Creating+an+UPDATE+statement) this problem can be easily solved.