I have only ever heard of people debugging production issues remotely; however, I have never participated or witnessed it myself. At my last company, we were restricted from debugging remotely due to worries about adding unecessary stress to the production machine. This seemed to make sense. And when detecting production issues, you have other alternatives (assuming you have a proper logging and instrumentation infrastructure in place): can either reproduce in staging or locally, or examine iis w3c logs, your error/warning/info log files, event viewer, or perf counters (depending on the type of issue you have).
Where remote debugging is particularly valuable is when you set up virtual environments for development or for the testers. Let's take the scenario where you have Windows XP installed but you are required to run in Windows Server 2003. What's the alternative to setting up VPC/VS? You can set up a dual boot on your machine. But you may be in a scenario where your debugging dialog boxes or other factors affect the ability to debug in a controlled environment. And as you know, virtualization is being talked about more and more; whether it is system administrators gathering all their legacy apps (I believe this was touched on in a DNR show), developers debugging or testers testing away.
Visual Studio makes the experience quite painless (esp if you are debugging .NET apps/web apps). I recall doing so in Eclipse for a Java app quite a while ago and not getting the same out of the box experience. Below are the steps for remotely debugging an ASP.NET app:
1. Get your VPC up and running on your network
2. Ensure that the pdb and dll of your local build of the application also exists on your VPC (I will assume that the website, virtual directories and app pools are set up).
3. Make sure that you have set debug flags to true in your config file(s) and that you have a debug build.
4. In Visual Studio, go to Debug -> Processes..
5. Beside the 'Name' label, type in the computer name of your VPC into the textbox
6. Locate the w3wp.exe (worker process) and attach to this process.
7. Set breakpoints in your source where desired. You will now be able to break here when your code path is executed.
Another added advantage to setting up a virtual environment is that now you have a disk image that you can easily share and reuse amongst your entire team or other team's sharing dependencies with you.