Logically, I believe in the concepts behind what the XP community refers to as Energized Work. Software engineering is a complex activity and it requires you to be fully engaged and focused. That is hard to do if you are working long hours. The problem I have with it is that over 20+ years of working as a software engineer, I have conditioned myself to work to the limits.
I was talking with another developer about this recently and I said that it really takes buy-in from management to make Energized Work possible. He turned it around and put the burden back on me. His thinking was it only worked if I made the decision to follow the principles and it would never work if I waited for someone else to make it happen.
That meant I had to make the decision to leave work at a regular time. That I had to make the decision to spend time with my family instead of sneaking off to do work. This developer and I have worked together in the past and he knows my work habits pretty well. His analysis stopped me in my tracks.
Bad habits are hard to break. One of mine is not being able to turn it off at the end of the day. I have to put the blame for that squarely on me. I have no problem saying to another developer “Go home, you’ll get it in the morning”. I need to remember to apply that advice to myself from time to time.
Old Dog, New Tricks 
Granted, I’m a young bud with far less experience, but when you work an 8-9 hour day, and then close the books, when do you find time to improve your skill set?
I’ve noticed that during task planning, nobody ever adds time for ‘Learn a good approach to problem X,’ it’s always ‘Implement X.’ So you can spend all day implementing X, but I don’t see where one gets the time to learn a better approach to implementing X if they don’t use time in addition to what’s been scheduled.
As an example outside of software development, doctors see patients all day. If this is the only time they worked, it would only be a short time before their knowledge (skill set) became tired, old and rusty. I’m sure there are plenty of doctors like this, but if I had to choose, I wouldn’t want them diagnosing me.
However, maybe there is something to be said for all the experience you have, and it’s no longer necessary to work so many extra hours since your base of knowledge is so vast. But I can’t help feeling that the young buds still have to go through some learning pains to achieve the level of zen that you have.
I guess it would depend on what skills you are interested in improving and whether they are applicable to the job you are working on.
Sometimes I enjoy trying out some new technologies that I am not using in my current job. I find this can be a break mentally from “regular work” and keeps me up to date with the current state of technology for the next opportunity that might come up. I normally don’t work on this type of “saw sharpening” at work because I can’t, in good conscience, consider it part of my job. There have been exceptions to this, but only with my supervisor’s knowledge and only then when there was no “real work” to do. So for me, that kind of learning has to happen on my time.
The other part of your question seems to relate to better solutions for problems that are part of your job. For that, I think pairing is a great way to go, assuming there is someone who knows something about the technology. Even if there isn’t someone with domain expertise, having two heads on the problem can keep someone from going down a rabbit hole (and never coming out).
Finally in regards to your comment about “nobody ever adds time for ‘Learn a good approach to problem X”‘, I think it is up to experienced developers to identify bottlenecks and schedule time to adequately address them. That might require some research or a spike solution, but to not plan for that time is a recipe for trouble.
Thanks for the feedback