I don't like the "deliberate choice or general incompetence" framing. It just isn't useful. What's both more likely and more interesting is to speculate on the specific mechanisms and forces that might lead to this sort of situation.

For example, perhaps the knowledge that firmware updates are possible for modern consumer devices means that the software teams have a higher risk tolerance when it comes to feature creep. They've been able to fix bugs in the past, and it was no big deal. It certainly wouldn't involve scrapping existing inventory or retooling anything in the production line like you might have to for a hardware defect.

Or, and this reflects my own experience as a software person, perhaps broader changes in software development culture are partially to blame. 15 years ago one of the first lines of defense for the team I was on was the project manager. As the one person whose only job was keeping a more holistic eye on the value chain, she often caught latent quality risks (e.g., the potential for two different in-development features to adversely interact) long before anything made it to QA. Nowadays most companies, in a lovely iteration of the doorman fallacy, have nixed that role because they believe Jira can do the job.

I've got similar feelings about Scrum. I have been on Scrum teams that were great at delivering consistently high quality software. But they were the exception. The more common situation is people rushing to merge a glut of changes on days n and n-1 of an n day sprint, every n days, forever. Which, regardless of what any manager says, is how they're de facto expected to behave. Taking two or three more days to get the job done properly would screw up the metrics on some KPI dashboard.