Good question. And:
> This framework is helpful for thinking about content
You are absolutely right, it doesn't prescribe four boxes for all content to be forced into at all costs, it describes an approach to thinking about what you are doing when you are writing and managing documentation.
As for your question: let's say you're flying an airliner, and for whatever reason, you have to make an emergency descent. You want to know what to do. You want a how-to guide. You turn to the EMERGENCY DESCENT page in the Quick Reference Handbook. It prescribes the steps to take, in the form of a list. It says: if this, then do that. You know what you want to achieve, then handbooks guides you through the actions.
A different scenario: you're at cruising altitude, and have to shut down an engine. You want to know what the situation is (what the optimum drift-down rate is, level-off altitude, and so on) given your current weight etc. You need information (reference). You'll turn to the ENGINE INOP page, where you'll read the numbers off tables. No instructions - just facts.
In either case, encountering a mixture ("pollution") of how-to prescription in the reference description (and vice-versa) would be at best unwelcome, at worst, deadly. Your needs are different in each case. You know when you want to know what you should do, and what you should know. You know when you need to flip from one to the other. Documentation should serve those needs, by keeping the material separate.
And pilots manage even without hyperlinks, which make it so much easier for our software documentation!