I like your idea of best practices for common use cases. But, also keep in mind that your assertion stands orthogonal to "Plone is a Contract" - i.e. the implementation details are left to the user. While the initial hurdle might seem high, Plone gives experienced integrators the ability to extend it and tailor it to their needs (Quaive, Senaite/Bika LIMS, Guillotina, PloneGov, Headless Plone/Volto Prototypes), with many of those technologies feeding back into the community.
This leads back to the question: what is Plone and who should use it? A CMS on steroids, a web-framework, or indeed simply a contract? Whether Plone is the optimal framework for your website/intranet/extranet is very much open for discussion... There is no "one size fits all", it is probably easier to say what Plone is not.
My take on this: if we want to make Plone more accessible to decision makers (technical and managerial), the place to start might be They use Plone Add more use cases and present those with better context: explain the considerations / alternatives, and highlight why Plone ended up becoming the chosen solution. Expanding this section of the plone.org site could form the scaffolding for guidelines/best practices in the scenarios you suggest.
I think Plone Distributions are also very helpful in that regard, together with training.plone.org, the excellent documentation initiative shouldered by @stevepiercy, Cookiecutter-Plone, and (past) initiatives such as the Plone Unified Installer or Plone in a Box that might be resurrected in one way or another.
As a new Plonista, keep giving yourself time to discover the advantages of a framework like Plone. When your intranet users inevitably demand features or workflows unique to your organization, you’ll see why Plone was the right choice. In the end, this community (and not just slick tutorials) is what makes Plone great.