The author seems to be trying to convey that the "quality" of a software product is often more about the perceptions and expectations of its end user(s), and not some quantifiable attribute you can apply to it (e.g. coding standards, design standards, security standards, etc), or the perceptions of its creators.
For example - a competent developer will point to an ancient codebase which has devolved into a "big ball of mud", written in an obsolete language, violates every modern design principle, is overflowing (pun not intended) with security flaws and backdoors, and is fragile for maintenance engineers, and has a diabolically unfriendly over-complicated UI, and say "This software is terrible!".
However, that same bit of software in the eyes of the end-users might do everything that those users need or expect it to do. Those users will not 'see' the horrendous codebase underneath, and any flaws which do appear are often able to be patched up some way or other.
To the eyes of experienced users of such software (and particularly the people who own the rights to use the software, and may have paid millions for its development/maintenance over many decades), if it's deemed "good enough" and "stable enough" and "does the job it's meant to do", then that will often earn a big rubber-stamp in the quality box.
This perspective isn't unique to software, although it's most commonly found in software because there are millions of businesses out in the world who still rely on software built decades ago; and their judgement of "quality" tends to be - "Does it make us more money than it costs us? (and/or would cost us to replace it)" and "Does it keep our reputation in good health?"
Could you apply this to other domains? Maybe, but it's a lot less common with "things" which are tangible, which can be picked up and held in your hand, and exist "in the real world" - particulary where physical/mechanical things have a tendency to decay and fade over time (e.g. Cars have a mileage, mechanical things wear out, things get damaged by over-zealous users, etc - software does not suffer from this!)
So, aside from the fact that code does not "decay" (Except through malpractice by software engineers), the inner-workings of software are so opaque, and users are so far removed from them, that the "quality" of the code, along with the security flaws, the usability problems and the obscure bugs/defects tend to be almost invisible to the average user.