I think there's domains where rigorously establishing requirements ahead of time is necessary and creates better outcomes than shipping quickly and iterating. Especially safety-critical domains. If your product can kill someone (either on failure or success), defining expectations, behaviors, and specifications ahead of time is responsible.
I see where you are headed, and certainly unscrupulous entities will it as an excuse to cut corners, but I think they are talking about the case where someone produces something that will clearly not work, while still meeting the letter of requirements. Having good requirements is important, but making them is iterative as well, and having to treat software developers like an evil DM when you are casting the wish spell is not ok.
Yes, I agree with 'Working software over comprehensive documentation.' It's that 'working' part that sometimes depends on getting the requirements right.
> "Meeting requirements is treated as more important than getting something useful into the field as quickly as possible."
I've got a bad feeling about this. It seems like the kind of attitude that leads to last Friday's Crowdstrike update.