The primary question is one of purpose: someone in a support role is hired to keep me effective and productive, and evaluated on their ability to do so. I am their customer. If I win, they win.
The goal of IT isn't good systems architecture or innovation -- it's me. Supporting me well often requires good systems architecture and innovation. It also requires compromising those at times to my goals, having clean transition strategies, and similar choices as well. Those decisions are made based on their impact on me.
I absolutely think you are wrong that innovating is derived from your needs, a technology group driving innovation could just as well include obsoleting you. An IT department can bring new business ideas to a leadership team, and arguably their leader is a part of that leadership team, at least until every c-suite person is tech savvy enough to obsolete the CIO position.
All of those things are there to support the business, not the other way around.
IT's role is generally to support the organization. The organization is its customer. For the most part, it doesn't "work with," but it supports. In any organization, there's a complex network of who is a customer, who is a client, who is a peer, and so on.
There are places I'm not IT's customer, but they're the exception rather than the rule. If IT isn't providing a service I need, then that's a failure of IT. At the end of the day, the fallback is to purchase the same service elsewhere. If IT needs to know about that (e.g. for audits or security), it's fine to have a process for that (I report to IT, IT verifies what it wants to), but if that process becomes an unnecessary roadblock (IT doesn't want to compete for my business, rather than a core security issue), either people will circumvent that process or the business will take a hit.
The customer-provider networks vary on business. In some cases, engineering is the customer of marketing, and in some cases, the other way around. You have companies where marketing decides what to build based on customer conversations, and engineering builds it. In other cases, engineering decides what to build, and marketing sells it. And then you have all sorts of cases in between, from synergistic peer relationships to all sorts of balances where one drives but the other informs.
That doesn't change the gross organizational dysfunction being described in this article.