In java persistence with hibernate, gavin suggests that we use business key for equality comparison. Business keys can not only involve multiple field comparisons, but there is no guarantee that the "perfect" business key's semantics will not change in future. We live in non ideal world and business requirements and laws change very frequently. In such case we will be left with data in db stored with multiple business key semantics.
I want to break problem into 2 parts
1. When we strictly deal with persistent or detached objects.
2. When we deal with transient objects.

1. I still don't see any downside on using a surrogate key for equality and hashcode if we are dealing with persistent and detached objects. 2 persistent objects or detached are equals if they same primary key . Is this wrong to assume ?

2. When we deal with transient objects, we can use the business key semantics to compare objects and have a merge strategy available if you try to persist 2 transient objects with same business key but different values in remainder attribute

In read heavy applications, where most of the transactions are read/update, this strategy should yeild a better performance. As, i am new to hibernate, any suggestions are appreciated.

Standard solution at my place of employment is to enforce all business rules at the database.
That would mean either performing all modifying operations through a stored procedure rather than using raw SQL on the database (or hql or jpql of course), and/or using triggers that call the validation logic placed in stored procedures.
That way the database will always be consistent, even if the application(s) attempting to write to it are not doing correct validation themselves.
It also means that there is no code duplication, with multiple applications all having to implement the same validation routines. Rather, they defer validation to the database and handle any errors returned.