Database mirroring is more of a high availability solution, not a disaster recovery one. What makes you think synchronous commit will lead to high latency in your environment? Are the principal and mirror server geographically separate?
Asynchronous commit will lead to potential data loss in the event that you need to do a forced service failover, therefore you would need to ensure that your SLA guidelines are congruent with that. BOL reference on Force Service in a Database Mirroring Session:
Forcing service may involve some data loss. Therefore, force service only if you are willing to risk losing some data in order to restore service to the database immediately.
And equally important, database mirroring is marked for deprecation:
This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature. Use AlwaysOn Availability Groups instead.
Is there a reason why you don't want to utilize AlwaysOn AG? See BOL for an overview of AlwaysOn Availability Groups.
AlwaysOn AG has all of the capabilities of database mirroring with many more advancements.