Perhaps you don't understand how it works.

With near synch, when the application commits, DB2 guarantees that the data
is written to the DB2 transaction log on disk on the primary server (this is
normal even without HADR), and that the log information is successfully
written to the HADR buffer on the standby server. So even if the primary
server crashes before the data is written to the log disk files on the
standby server, it is in the log buffer on the standby and will be written
to log disk on the standby within a very short amount of time (it will not
be lost). This would happen before a takeover to the standby would take
effect.

Therefore, unless the standby server crashes within a few seconds of the
primary server crashing, you will not loose any data. The odds of both
servers crashing within a few seconds of each other are astronomical.

Keep in mind that if both primary and standby server did crash within a few
seconds of each other, you would know that, and simply choose to not do a
takeover to the standby (or a takeover by automated means would not be
possible because the standby server also crashed). So in this situation the
standby would not actually loose any data, since it would never be used as
the primary.

If your primary and standby servers have a slow network interface between
them, you are not EVER going to get the same level of performance as you
would without HADR. But even if they are close, "near synch" provides much
better performance in a high transaction environment, at only a miniscule
risk (actually non-existent risk IMO).