I use logging fairly often, especially for applications that are heavily dependent upon unmanaged resources that I have less control over (network I/O for example), and for applications that are difficult to debug properly from within Visual Studio. There are also things that you might want to log in the production environment that you can't log just through debugging, such as user activity, unexpected occurances / exceptions, etc.
For example, at work I recently wrote an application for data transfer. I had to figure out a way to transfer data from an external server that I control to a server within a government network that I control. Large amounts of data have to be transferred daily. I exposed the external data by developing some web services for the external server. Then I wrote an application that is scheduled to run periodically on the internal server. The internal server passes authentication information and requests for specific data to the external server via SOAP headers. The external server then returns the serialized data over HTTPS via XML. Because there is a large amount of data involved here, the fact that we have a contractual requirement to keep the data up to date and available on the government network, and because of the fact that I am relying on ISP networks which I have little to no control over, I need to be able to log what goes on with the data transfers so that I can troubleshoot issues. The data transfer software keeps its own logs and also logs events to the event viewer for the server. Then I expose this data via an intranet website so that I can quickly check the status and health of the data transfer system and the internal database.
I also use logging for security purposes in my production applications. Some of my web apps log user activity for example, and most of my web apps will log any exceptions that they encounter into a SQL Server database so that I can catch and fix bugs quickly.
Another scenario where I recently used logging was when I needed to quickly install some event handling routines on our SharePoint server. I didn't have time to set up a proper virtualized environment for sharepoint or a test server either. I added the SharePoint.dll to a project and wrote the code, read through it meticulously and made sure it compiled, but I didn't have the proper environment to actually run the code and attach it to a debugger. So as I was developing the application I would periodically install the assemblies to GAC on the server and register them with sharepoint using an in-house utility that I wrote. I had the event handlers write a lot of informatino to the event viewer on the server so that I could see that they registered with SharePoint and were working properly.
As far as common practices go....one thing that I always do in all of my .NET classes is override ToString(). My ToString() override generally returns all important state data for my type (properties and member fields, etc.). This is useful for a lot of reasons, and logging is certainly one of them. If you are trying to hunt down an issue or keep track of things in the production environment you can leverage ToString() a lot in order to log a printout of a types state at any given time.
You can use the EventLog class in System.Diagnostics if you are a .NET developer to write straight to the Event log of the system if your code has the appropriate permissions. You can also use System.Diagnostics.Debug and System.Diagnostics.Trace for logging purposes. Trace is useful because you can write directly to the output window in Visual Studio which goes hand-in-hand with debugging. You can also create your own Performance Counters for your application for use with the Performance Monitor mmc snap-in in Windows. In reference to your question, you can see that Microsoft considers logging to be a common requirement for a given peice of software, in fact, many if not most of their applications employ some type of logging.
So to answer your question, yes, logging can be very useful, and is in fact very common.