A lot of this pain is self-inflicted by Big Co., your employer in your specific case but I'm not picking on you in particular just offering some observations.
I take it you haven't gone through many large companies' procurement processes and procurement culture as a vendor. It literally takes entire man-days to man-weeks of effort (and for especially large and/or complex requirements, man-months to man-years) to respond to the procurement demands of these large companies, and vendors know it is a "my way or the highway" arena with these large customers. Perhaps the software might not work for you, but for varying definitions of "work", it satisfies one or a consortium of constituencies within your company. You, personally, are simply not at a position of sufficient power within your company to be privy to what that specific definition of "works" is for the specific software that is used by your company.
You probably haven't had the pleasure of working many months over an RFP strictly gated by the procurement staff, with only two one-hour, chaperoned meetings with the technical staff to attempt to clarify wildly lost-in-translation contract verbiage. Generally the more clarifying questions you ask, the worse the procurement team looks, and the more hostile they are towards you, so you also have to carefully choose your questions. And a good proportion of the time, you only find out after losing the bid that they dragged you through all that pain and suffering simply to get a number to beat up an incumbent over the head with to get a lower maintenance renewal, all along never intending to consider any change at all, and never admitting during the process they even have an incumbent solution in place already in the first place. The chaperone from procurement actively monitors and mutes the technical staff during the conversations, to prevent the technical staff from divulging whether or not a solution is already in place, for example.
This and other behavior forms an enormous torrent of obfuscation from the customer base; it hugely bloats the sales costs. This is what incentivizes the production of the software you experience, because it sells. There are many big companies who are happily using open source alternatives for all sorts of requirements, but when you see poorly-fitting software in the trenches, a lot of the time that is produced by a severe disconnect between the procurement process and the trenches at the customer itself. Sometimes this communications gap stems from the procurement department, sometimes from the trenches, sometimes from the company culture, etc.; the reasons are all over the map and I've never discerned a pattern, but the gap is real and problematic.
I should touch upon internal customer political factions that muddle the picture even more. When these political factions are not managed by a single strong managerial hand, this frequently causes the design-by-committee feature bloat you see, because different factions demand all sorts of features for their specific concerns to obtain their "buy in", with no coherent guidance that prioritizes and establishes required features to meet a focused, accomplish-able goal. This also produces the ironic result of software procured that meets all the official, politically-sanctioned requirements, but does not meet the daily needs of the trenches. I won't even go into the dynamics of dealing with political factions who are at odds with each other.
There are solutions to this state of affairs, but customers by and large turn away from them because buying these packages and services is to the decision makers at these customers less painful than the alternatives. It is maddening and infuriating to outsiders not already familiar with the workings of these processes, but outsiders can take heart that the situation is slowly changing over time as better technologies evolve.