The expense (time or otherwise) follows from how intimately you have to get to know the subject. Which is precisely why it's the best way to learn. It's not always viable, but when you can spare the expense nothing else compares.
Same can be said of learning a large inherited codebase. If you're assigned to a large piece of functionality and you need to understand it, your first instinct shouldn't be to rewrite the whole thing from scratch just to understand it; it should be to either read the code and documentation, or if those are impossible to comprehend, ask around what it's supposed to do, maybe even write tests to get a general sense of the behavior.
I don't expect programmers to be cognitive psychologists here but the thing about learning is that you must do a "progressive overload" of complexity as you go, which is why building on top of what exists is the best way to go. You get a general idea first of what something is supposed to do, and then when you're good enough, that's when you can work backwards to building something from scratch where all the complexity at lower levels of abstraction wouldn't be too much for your brain to handle. Starting with a large amount of complexity will impair your learning and only discourage you.
Personally, I’m a fan of learning by doing. Reinventing the wheel works better for me than just about anything I’ve tried.