You will definitely find more using clustering than Mirroring simply due to
the fact that Clustering has been around so much longer than Mirroring.  But
what good is asking what someone is using without knowing why?  Like any
feature both have pro's & Cons.  Just because someone else is using
clustering does not mean it is the best for you or the next guy.

You would be surprised at the current cost of clustering.  You can get a
two-node cluster with dual-core, dual proc hosts for around $35-40K,
including SQL licenses.  If you need quad-proc hosts, the price jumps to
around $100k.  Before SQL 2005,  it would take $80K just for the lSQL
icenses.  The cost of clustering has come way down in the last year.  Of
course, you still need the personnel and infrastructure to support a highly
available system, but that is never going to change.

Are people eating apples or oranges?  This isn't a simple plug it in and it
works.

I've seen clusters that worked very well and ones that were complete
disasters.  Niether one had anything to do with the technology.  The ones
that were complete disasters deployed clustering, without ever considering
what it was they were trying to accomplish or if it would even meet their
business requirements.

I've seen the same thing happen with replication, log shipping, 3rd party
products, and backup/restore.  95% of the work you do for HA has absolutely
nothing whatsoever to do with a particular technology.  5% of HA is the
technology you deploy.  So, the question becomes, which makes more sense
worrying about the technology (5%) or figuring out all of the business
requirements along with what you are protecting and why (95%)?

If I may interpret 'mirroring' broadly (more broadly than as is used in the
SQL2005 Database Mirroring feature), we use disk level mirroring between
geographically dispersed data centers, and clustering locally within a data
center. This combination has worked out very effectively.

Linchi