In broader terms, all logging goes in framework-level code. For smart clients, one really good place to put logging is in your Command infrastructure - every time a command is invoked, log it and the args. For data access, well, any decent O/R Mapper has a lot of logging already, just use it. For communication, ditto. Funny that just last week this was one of the major bits of feedback I gave in a code review.
Logging is for troubleshooting, nothing else. They are incredibly helpful when you need to find out what the hell is going on, but they are very bad in the other two tasks that are usually assigned to them. Alerting you that something is wrong and getting information out of the application during normal operation.
Alerts are raised when something in the application has gone wrong. Maybe a circuit breaker tripped because an external system is failing, or maybe disk space is getting very low, or a batch process failed, etc. Those alerts should be wired into whatever monitoring system your IT team is using (ArcSight, MOM, Nagios, etc). This is important. Trust me on that.
The other aspect is auditing. I want to know who changed what as well as when and why. In on of my projects we had an ISystemUsage interface, which controllers would call to inform the system about interesting things happening. This is at a much higher level than logging. We aren't interested in the raw details, only in business significant data.
If I recall correctly, the data we gathered was about logins, view data, failed searches, feature usage, taken actions, etc. That let us reconstitute the activities of user at a later data, as well as mine some fairly interesting out of the system.
Udi suggests using a Business Activity Monitoring system for doing this. My only experience with BAM was with BizTalk's so I have bad impression about the name, but in general, I agree. You want to give as much visibility as possible into the system.
Oh, and read Release It!