This doesn't really have much to do with Agile, or even with Software Engineering. It is simply true of any company in any business: you need to set aside time for training. Period.
Agile has this idea of "sustainable pace", which means that, at no point, should the team work harder than what it could sustain for an indefinite amount of time. I.e. no "crunch time". This needs to be honored by training as well. So, it a sustainable pace for your team is "no more than 5 hours straight without break, no more than 9 hours per day, no more than 40 hours per week", and you want to provide 10% time for training, then you need to plan your projects for 36 hour weeks.
But again, this has nothing to do with Agile, that's just common sense and primary school math.
Personally, I would think that something like allowing for half an hour per day, one half-day per week, and one full week per quarter would allow the team to acquire different-sized chunks of knowledge quickly and at a steady pace.
There are also some Agile practices that help with knowledge transfer, i.e. to smooth out differences in the level of knowledge across the teams:
- daily retrospectives
- retrospectives per sprint
- retrospectives per project
- pair programming
- ping-pong pairing (swapping the driver and navigator after every step of the red-green-refactor cycle)
- promiscuous pairing (no fixed pairs, pairs are assigned randomly and changed every morning and lunch)
- odd number of team members (if you do pair programming, leaves one team member free to learn)
- mob programming (a variant on pair programming where the entire team uses a single computer and screen, a designated team member is simply a "typist" and the others tell him what to write)
- promiscuous teams (developers are randomly assigned to teams every day / every sprint)
Pair programming and mob programming not only provides continuous code review but also continuous knowledge sharing. Ping-pong pairing prevents one person "hogging the keyboard". Promiscuous pairing spreads knowledge through the entire team, promiscuous teams spread knowledge through the entire company, and ensure that every developer knows every project and every codebase; it will also lead to a high degree of standardization in the codebase(s). While the prime focus of retrospectives is to provide feedback on the development process and adapt accordingly, it can also be used to communicate an uncommon issue and how to solve it.
It should go without saying that the employer should provide an extensive library, paid subscriptions to ACM, Springer, IEEE, etc., as well as quiet rooms to study in and larger rooms to teach in. Lots of whiteboards and flipboards, as well as projectors everywhere are of course sensible in general, not just for training.