It's worth asking, "What is an API Gateway used for?"
The answer, typically, is "For providing public, programmatic access to service control planes."
Dig deeper. "Which parts building service control planes are hard? Which difficulties are directly related to providing public, programmatic access, but don't typically fall under the control of an API Gateway? Which parts have gotten harder over the past ten years? Why?"
Or, asked another way: "Which parts of a traditional API Gateway are the way they are... simply because that's how they've always been?"
For many larger organizations, SOA is still more theory than practice. There's a long tail of dependencies in many legacy systems. Teasing them apart, clustering related subsystems, and opening up access without overwhelming those systems requires intentional investment. Realizing the long-term upside of that investment requires foresight and—often—a willingness to put other, more immediately tangible investments on hold.
So... the flip side: "Which aspects adopting a traditional API Gateway make it out of reach for legacy systems? How do you reduce that activation energy and time-to-value?"
Lastly: "Where is there meaningful overlap between the answers to these two questions?"