I'd wager reading that book and spending years trying to shove the patterns into things is a net benefit iff you learn from it where and why the patterns were appropriate or not. I've never read one of these books, but a good one should give examples of when a pattern is counterproductive.

In a greater sense, in our profession we tend to learn about new hammers by forcing them into the next (work or personal) project that vaguely resembles a nail, and I think that's largely OK if the alternative is stagnating.

I'm a fan of teaching people the wrong way first, then ask them if they can find ways to improve the situation, and only after that give the "best practice" solution.

Doing things the wrong way shows them why, asking them to try to solve it themselves teaches them under which conditions the issues present themselves -- this is actually the most important part, don't write 200 lines of abstraction just to work around the fact that you use a paltry 4 globals.

It might be great for the person, but it's sure a drag to clean up after people learning to use a hammer by smashing anything they can find.

Actually, a better way to learn these patterns might be to clean up existing code. If the pattern is applicable it should then simplify and clarify the code. You'll also likely to run into crud left by other people, and will learn the appropriate level of disgust