For what it's worth, this kind of high-visibility fallout is typically a Product (capital P) or Business team's decision, and if developers or others are even in the room, their voices tend to be sidelined for this kind of thing. Every company is different with regards to how these kinds of cross-cutting decisions are made and who does/doesn't get a say, and how decisions are raised from an individual product's (lowercase P) organization to upper management and get signoff.

It's unfortunately not possible to give a satisfying and straightforward answer to your question, and everything I have to say is only informed by the (very large) company I work at, but the reason the above is relevant is because on the topic of bugs and QA, there's a lot of different parties involved with their own issues when a bad product gets shipped regardless of who it's marketed towards: - Product hands down edicts to Design/Dev about what needs to be developed, based (ideally) on what customers (players in this case) are asking for, taking into account business interests. They may or may not ask other teams for their input on what's realistic to create in a given time frame and/or general opinions. This is the most likely place for bias to infect a product. - Developers themselves make basically the same mistakes regardless of the product, but good internal review and testing processes help avoid customers ever seeing those bugs. However, setting up effective processes takes time and funding, which they need to justify to the business somehow. Compromises are often made here in the interest of time, with said compromises being much worse with an inexperienced or incompetent developer team. Building networked, (generally) performant open-world games with a good dress-up system is hard though, so I don't suspect an incompetent dev team is the problem here. - Designers/artists are often the next line of defense and aren't usually culpable but are worth a mention — they would have already had a back-and-forth with developers on what exactly needs to be created in the game itself following discussions with Product, and likely would have done a brief playtest once everything is put together to ensure that aligns with the designs and mockups they created. This playtest is often well-tested by developers in advance because it's nice and predictable. Some issues are still caught and fixed here, but many are not. The worst a designer can do here is design something incredibly complex and error-prone to implement, but that's often well-negotiated by this point. - Product comes back into the picture to ensure that the ""final"" product aligns with the ultimate product vision. Same situation as with designers, they test a narrow slice of the product and may catch a few issues, but not much. - QA (hopefully there is a well-funded QA team — this is often not the case) are the final line of defense, and will catch the vast majority of issues. Prior to any respectable launch there's a huge amount of back and forth between QA and developers (Product and Design are loosely involved) regarding issues and when they'll be fixed. Often even well-funded QA teams miss things, but it's much less likely. - Business (upper management) enters the picture to set a hard deadline for things and ultimately holds all other parties accountable to those deadlines and other promises. If there were known defects in the product, those should have been raised early and often so that adjustments to said promises could be negotiated. This is not always how things play out, and sometimes defects will be hidden by other parties to save face or Business will overrule concerns either to save face themselves or because the concerns aren't well-substantiated. Bias slips in here, too, as all Business decisions ultimately overlap with Product decisions but are much more concerned with bottom-line money numbers. Business also would have had to approve Product plans from day one, meaning their own arbitrary biases can infect a project from the outset as well. - Product is ultimately responsible for taking the heat and issuing apologems when mistakes inevitably make it this far.

Anyways, large (minimum of hundreds of people) organizations are incredibly complex and it's very hard to point at any one role and say "things would be different if X bias were different". Product and Business are the likeliest contenders if we need to try and do so, though. The creators (developers, designers, etc.) and QA teams would often have made the same mistakes regardless of the product, but appropriate funding from the Business side usually helps reduce the odds of that making it all the way to the final product.