This is mostly just a philosophical question.
I am looking at integrating GTM and implementing Enhanced ecommerce tracking with it, and the more I look at it, the more I feel like these two are fighting each other.
GTM seems to encourage a seperation of concerns from the web app, where the app exposes generic data points to the data layer and a "Markerter" or similar sets up tags in GTM using those variables.
However, the recommended way to implement Enhanced ecommerce is to add very specific data directly into the data layer, and just tick a box in GTM. This means that the data layer is no longer generic, and you cannot implement Enhanced ecommerce without changes to your backend or "without IT dept support" as GTM likes to advertise itself.
Am I missing something or is google not eating its own dog food here??
I think you should remove the first sentence in your question.
Not philosophical, but as a matter of how code is organized in GTM: The idea that you can implement GTM without the help of an IT department has been BS all along. You need to get the data from somewhere, and the only stable way to do this is a dataLayer unless you want to couple your tracking to the more ephemeral aspects of your Website (DOM, urls etc.) which will fail sooner than later.
That a specified datalayer is required for Enhanced E-Commerce tracking seems to be mostly a practical decision; else you'd need a strange plethora of input fields and variables for the Google Analytics tag if you plan to use E-Commerce-Tracking.
Also you do not have to use the dataLayer; you might set the input for Enhanced E-Commerce tracking to a GTM variable, which might itself be a function that retrieves the data via some other means than a datalayer (DOM scraping, global variables, ajax calls, you name it). This is not necessarily a good idea (doing things in a browser that a server can do faster and more reliable generally isn't), but it's entirely possible.
So Google can both eat its dog food and keep it by offering a choice on how you want to do things.