Isn't there a catch, at least in the US, that companies don't want to invest in training/mentoring because they believe once they reach a certain level the people will just leave and employees that don't feel like they're being trained/growing in their role will also start to look to new pastures, esp. if pay is keeping up with their skills?

I was recently laid off from my job. I was #2 in a two-person IT team (#1 had been there for 20 years). I came wanting to be mentored and to learn but the string of broken promises and lack of any sort concrete plans left me adrift so I continued to self-train. After expressing this sentiment to the boss, thinking an open and honest dialogue about where I hoped to be and that I felt neglected in terms of the company investing in me (whereas the other users received an educational stipend, paid for professional study and exams, etc.), I was told we'd come back to it after our office move earlier this month. Well, we did, and I was let go.

I don't disagree with your main point, and I think the apprenticeship model could work wonders in many tech environments. Harder to implement when you have a very migrant worker population, even at normal rates of turnover.

There is however some merit to writing down details to critical or seldom-used processes in a communally-accessed place such as a wiki. Keeping it up to date and having someone review it regularly has to be part of the process.

Build instructions, and dependency assumptions for starters.

Sometimes the hardest part is just figuring out how to get a project running, or learning what kinds of settings need to be enabled on deployment.

As for craft and actual in-code understanding, I think the masonry example can fit well (see pair-programming as a more fluid example of this). Granted, if you have an API, you probably want to at least document the interface with an example of how to call it. The complex bits of "how is this architect-ed can be better taught by 1:1.