There's different kinds of training and there's different kinds of ways to offer it.
If you need training for a specific tool that you're team is using, or would like to use, you'll have to show that:
- This tool/technology will make the whole team more efficient and less costly and benefit the whole company in a direct or indirect way.
- Learning the tool/technology is not trivial.
- The developers would benefit from formal training as it would reduce errors introduced when learning on the job.
This might not apply to all new tools or technologies, but if formal training reduces the learning curve and possible errors that might be introduced by the trial-and-error approach often found when someone just learns bits and pieces as they need them, that could be a strong argument.
If you want more general training, such as "best practices of JavaEE web apps" or "effective unit testing", you might have a harder time with this. You could try a less formal approach, such as having "lunch-and-learn" workshops where developers listen to a talk/demo over lunch hour given by one of their peers who is expert (or at least more so than everyone else) in the subject.
This approach might not teach as much, but the informal nature makes it easier to organize, and if management is willing to buy pizza and let the developers organize their own training talks it can still be effective. Management may also like this approach since it runs over lunch so they don't really lose any working time - although they should be nice and spring for lunch. Also, I'd say it's important to not make these sessions mandatory but try to get people to participate voluntarily. Offer incentives such as a quiz with prizes (extra pizza or something - doesn't have to be too glamorous, but should be fun).
And finally, there is training for business-related subjects that could be of use to programmers. For example, an insurance company or bank might want its programmers to take some basic training sessions in the business side of what the company does. This is usually done to make it easier for the programmer to understand business requirements and to interact with other people (business analysts, testers, end users) when discussing non-technical aspects of the system. Usually this would be done if the programmers are expected to understand more than the absolute basics of the subject area in which they are programming.