Nice summary of database mirroring as side note I came with 13 reasons why you wouldn't use database mirroring:

1. Disk space – unlike SQL Server clustering a separate copy of the database must be maintained resulting in twice the amount of disk space. This is a big deal for VLDBs
2. SAN fabric – One of the arguments for DM is since you have separate disk copies you eliminate a disks as a single point of failure. This is only partially true, since all SAN connects are routing through a single SAN fabric
3. DM only addresses a single database and non-SQL Server services will not failover. Examples include Schedulers, and backup agents
4. Requires application changes in order for automated failover to be used. Either SNAC or ADO.NET 2.0 must be used in application code, so that the application is DM aware
5. DM uses source, mirror and witness. The witness will require an additional SQL Server license albeit a small per seat license
6. Need to maintain logins manually on both servers since this is at the instance level and DM does not cover master, model or msdb
7. DM does not handle failing over of SQL jobs, downloads, or external jobs
8. Async uses single thread for DM
9. Performance – higher log generation, network latency with Safety-full less tran/sec on source system
10. Log growth issues until mirror is available even though tran has committed on principal
11. If witness is lost no auto failover. Mirror loss tran log grows until available. Witness and Mirror loss everything stops
12. Transactions can take twice as long to commit with full-safety
13. Database Mirroring is a physical operation i.e. equivalent to log shipping/DB restore and not a logical operation like replication or Oracle Data Guard making it more likely to encounter issues and difficult to use as a reporting server (granted you can do some kind of lame database snapshot).