IMHO using an OO domain model for most applications increases development time and complexity. The DataAccessCommand pattern leverages the power of the database but provides an OO abstraction to the datasource. The DAC object can map db columns to custom types such as Currency and provide validation and formatting services. There is also less overhead involved and complete control on the SQL statements.
However what are the disadvantages of the DAC pattern?
What isn't possible with the DAC pattern?
As a general rule, the tradeoff between OO and non-OO techniques (like DAO vs. DAC) is ease-of-development vs. ease-of-maintenance. Procedural techniques like DataAccessCommands tend to scatter logic in multiple locations which makes things more difficult to maintain.
The classic example is scattering validation logic in multiple procedures. Your suggestion of mapping data values to custom types like Currency will help minimize the problem, but only addresses single-field validations. What if you have more complex validation logic? For example, your maximum loan amount (a currency value) depends on the loan type (a different field in the same table).
Having said all that, sometimes faster and simpler development is more important than maintainability.
What about storing validation rules as metadata (in the database)? Then you can have generic services to check validation. Also wouldn't this only be a problem when the same entity/object is modified from multiple screens?
Basically you have hit the nail on the head. So long as everything is simple (such as one screen maps to one table), the procedural approach works fine.
When things get more complicated, with data being manipulated in various ways from different screens or even different applications, the extra work of OO pays off. And then there are other concerns like logging and transaction management and security and on and on.
You can push more logic into the database with complex constraint rules and stored procedures, but that is only a delaying tactic, not a solution.
Then again, if you expect that your application will never grow beyond its simple roots, the non-OO approach may work fine for you.