A decade ago, there was lots of talk in the #drupal community about doing things “The Drupal Way”; the big perceived problem in Drupal builds was people just slapping Generic PHP App on top of Drupal, rather than using its event system, DB and theme layers, content model…
Over time, the “build-out” process for a Drupal site moved away from “lots of custom plugins, plus content”, turned into into configuration and integration of relatively mature pre-existing plugins.
The problem is that we now have quite a few “Drupal Ways” to do things — deeply divergent philosophies about site architecture, content modeling, editorial workflow and governance, etc. And all of them are implemented “the right way” as far as Drupal’s APIs are concerned.
The good news is that there are far fewer situations where flat out terrible and inappropriate code has just been dumped onto a D8 installation, and won’t interoperate with anything else. What it DOES mean is that deep understanding of an org’s problem domain is essential.
…As well as deep understanding of the pros and cons of different “Drupal Ways”, and how well their strengths and weaknesses match the needs of a given project. “Paragraphs is better than Entity Embed” (or vice versa) isn’t just untrue, it’s the wrong question to ask these days.