Then it’s a matter of how well your engineering/ops org is setup to deal with silly hardware issues and annoyances. Some orgs will burn dozens of hours on a random failure, some will burn an hour or treat the entire server as disposable due to aforementioned cost differences. If you are not built to run on cheaply engineered gear that has lots of “quality of life” sharp edges (including actual physical sharp edges!) then you are gonna have a bad time. Silly things like rack rails sucking will bite you and run up the costs far more than anyone would expect unless you have experience to predict and plan for such things beforehand.
Of course you do have the risk of a totally shit batch or model of server where all that goes out the window. I got particularly burned by some of their high density blade servers, where it was a similar story to yours. Total loss in the 7 figures on that one!
Totally agreed on their BMC/firmware department. Flashbacks to hours of calls with them trying to explain the basics. My favorite story from that group is arguing with them over what a UUID is - they thought it was just a randomly generated string. Worked until one didn’t pass parsing on some obscure deeply buried library and caused mysterious automation failures due to being keyed against chassis UUID… and that’s when they’d actually burn one into firmware in the first place.
It was also always a tradeoff of having to deal with cheaped out hardware engineering with supermicro or with some horrible enterprise quarterly numbers driven sales process with Dell.
Oh and you'd get fined for damage to the pavement.