(The commercial use we were putting it to: part of a compiler chain for the red button functionality on satellite TV. Remember: if you're selling crufty proprietary vertical market software for $10k/seat/year, always put "Open" in the name.)
I realise this is anecdote wars, but nevertheless it'd be interesting to know where it falls down.
It's generally the more complex and cutting-edge stuff that makes use of newer pieces of .NET, DirectX, or rarely-used components of obscure APIs that WINE struggles with.
Unfortunately, a large amount of the interesting Windows-only software incorporates some of that stuff in one way or another. That's especially the case with games, which usually require very specific hand-optimization that invokes a lot of tricks. Then, to improve performance on AAA releases, driver vendors release updates that stack hacks-on-hacks. That makes gaming pretty tricky to successfully execute at performance-parity in WINE.
I don't mean any of this critically, just addressing the issue. It's absolutely amazing what Alexandre et al have done so far. WINE is one of the most impressive software projects in the world, IMO. I was lucky enough to be able to contribute to it in a small way myself (patches to a prior generation of the audio engine). For many years I refused to play any game that didn't run well in WINE.
Just this May, after 10 years on Linux desktop full-time, I switched back to a Windows desktop to get native performance out of my photography pipeline -- VMs just weren't cutting it, and WINE was a long way off from good support. Definitely a sad thing for me on a personal level.
Yeah, this is why Wine tends to use the "get the application to work" method. Thankfully a lotta the guys at Codeweavers are gamers who want their stuff to work too ;-)
.NET is a friggin' nightmare IME, even after you've installed over half a gigabyte of Microsoft downloads.
