I'm a developer in a company whose products are deployed overseas. When a support team comes in asking about a problem definition, my only tools for diagnosis are my log files and a copy of the customer's database. Using the database and my development environment, I have the opportunity to reproduce the erroneous case, because I log the incoming data to my module and the related actions. If I can reproduce the error with the help of the data I gather, then I can fix it with debugging. If I had no log files, then I would have to depend on the customer's or the support team's description of what happens in what case (which has a big chance of misleading).
Secondly, logging gives me the chance to detect the bottlenecks of my module at the deployed site, since I log the date&time of certain actions and then I can have a look at which action consumes how much time.
In addition to that, suppose our solution consists of 6 modules and I'm seeing error logs in my log files about database timeouts. If these errors are logged in 5 of the other modules too, then the probability that this is an SQL server related issue gets bigger. If this is logged only in my module, then the probability that my queries are buggy gets bigger. I think these kinds of things are useful indicators.
About what kind of data I see in my log files depends on the configuration of the log level. If this is a new product, we set the log level to "All" to gather as much data as we can. But when we improve the product, we may prefer to keep the log level at "Error" to log only the error, but not the information level logs, etc...