Then there is the infrastructure/deployment team and finally the developers.
At least in larger organizations i think that is a common way of doing things.
The article suggests using a higher level abstraction with better tools suited for the developers than the low level tools as docker, Kubernetes etc. You can make this into a separate internal product and still keep the devops idea. But as soon you break out any of the core responsibilities for the product from the team. If that's business, security, stability or quality you are moving away from devops. Sure devops isn't the solution to all problems. But why call it devops when one doesn't like the basic devops idea.
IMHO I would guess they're too close to the dev people to care about the bigger picture