Knowledge is great: I suspect we can agree there. Sadly, though, we can't guarantee ourselves infinite time in which to learn everything eventually, and in the meantime, there are plenty of situations where having irrelevant knowledge instead of more instrumentally useful knowledge can be decidedly suboptimal. Therefore, there's good reason to work out what facts we'll need to deploy and give special priority to learning those facts. There's nothing intrinsically more interesting or valuable about the knowledge that the capital of the United States is Washington, D.C. than there is about the knowledge that the capital of Bali is Denpasar, but unless you live or spend a lot of time in Indonesia, the latter knowledge will be less likely to come up.
It seems the same is true of procedural knowledge (with the quirk that it's easier to deliberately put yourself in situations where you use whatever procedural knowledge you have than it is to arrange to need to know the capital of Bali.) If your procedural knowledge is useful, and also difficult to obtain or unpopular to practice or both, you might even turn it into a career (or save money that you would have spent hiring people who have).
Rationality is sort of the ur-procedure, but after a certain point - the point where you're no longer buying into supernaturalist superstition, begging for a Darwin Award, or falling for cheap scams - its marginal practical value diminishes. Practicing rationality as an art is fun and there's some chance it'll yield a high return, but evolution (genetic and memetic) didn't do that bad of a job on us: we enter adulthood with an arsenal of heuristics that are mostly good enough. A little patching of the worst leaks, some bailing of bilge that got in early on, and you have a serviceable brain-yacht. (Sound of metaphor straining.)
So when you want to spend time on learning or honing a skill, it makes sense to choose skills with a high return on investment, be it in terms of fun, resources, the goodwill of others, insurance against emergency, or other valuable results. Note that if you learned a skill, used it to learn a non-customized fact, and do not anticipate using the skill again, it's not the skill that was useful; the skill was just a sine qua non for the useful fact, and others don't have to duplicate the research process to benefit. A skill that yielded one (or more) customized facts - i.e., facts about yourself, that you can't go on to share straight up with other people - might be a useful skill in this way, however.
For practical daily purposes, what is your most valuable skill (or what most valuable skill are you trying to attain now)? Post it in the comments, along with what makes your skill valuable, tips for picking it up, and what made you first investigate it.
My most valuable skill I can think of is in the context of being a software developer. I've learned to be pretty good at extracting requirements from customers. I often say this is one of the more important skills a software developer can learn. It's important at all levels of the profession, and is really a gateway skill to performing at a high level.
The reason it's important and hard to learn is that most of the time, customers don't know what they want, or they have an idea in their head, but they're wrong about what will satisfy. Extreme Programming (XP) teaches one approach that lets you get by with less of this skill, and that's to build something simple that approaches what they say they want, and then keep adding stuff until they're happy with it. But if the customer is really confused (which happens more often than you might think) then you'll have started in the wrong direction, and the customer won't get less confused about what they want.
So it helps to know how to talk to the customer and find out what the real problem is, rather than just what they think the solution might be. It's also valuable to have good intuitions about features they're likely to want that they haven't asked for yet, so you can build in the hooks for those. But if you make too many guesses, you'll waste time building general support where it's not needed. So you have to calibrate your guesses as well.
I'm a programmer but have worked as a more general engineering/management consultant and attest that this skill is valuable for more than programming. "Extracting requirements" is pretty close to "looking at the problem and figuing out what interventions (tools, systems changes, training, outsourced services, etc) would fix it", which is pretty obviously pretty generally useful.