I think you have to keep in mind how IT contracts and purchase decisions are made in large enterprises. You will almost never have an on-the-ground engineer making those decisions. CTOs collect requirements from other high-level managers who collect requirements from other managers and eventually a final list of checkboxes bubble up to the CTO. The CTO evaluates the asks and comes up with their own checklist of features they are looking for then go shopping.

Solution providers then try to check as many boxes as they can on the list. It doesn't have to make sense; you just want to check the box. When a decision is made, the chosen solution gets to the individual engineers to "figure it out". There is also a considerable amount of CYA in all of these decisions. You never want a project to get delayed of not implemented because you as a CTO forgot to check a box. The engineers using a product could decide that the box check doesn't work for them and they can then workaround it, but management (and the solution provider) get to CYA based on whether a box is checked or not.

My favorite flavor of this is when things are lost in translation, and a box gets accidently checked without understanding the actual requirement. Then it suddenly becomes a de-facto feature request because "the box was already checked".