"However, as a customer, I have no ability to use this information to assess the professional's quality." I do. Well, almost. Specifically, I can use metainformation to assess the professional's intentions. Occasionally, this will fail, because some people can say "the right things" and do terrible work, but if this happens commonly in some context (some industries, some geographical locations), then I will probably learn about that in advance.
I don't compare "refactoring or not" to "which scalpel do I use for surgery". That compares more to "which IDE do I use" or "which programming language do I use" or "which database management system do I use". The scalpel is a tool; but refactoring is a technique.
Different surgeons use different techniques. Not all surgeons can use all available techniques. Not all surgeons even know about all available techniques. Some surgeons specialize in a technique. I consider refactoring (really, evolutionary design in general) in this category.
Bigger, we have differences in approach. Some doctors (not surgeons) do not understand about low-carbohydrate diets; some doctors know about them and have wrong impressions about the results; some doctors know about them and argue about the evolving understanding of the underlying biochemistry. I know this: I ate 95% fewer carbohydrates and lost 70 kg in four years. I know this: when I eat more carbohydrates, I gain weight, and when I eat fewer carbohydrates, I lose weight. Unfortunately, this means that I can't benefit from a doctor who believes that eating low in carbohydrates "doesn't work". I consider evolutionary design in this category.
So once again, even if my Customer can't judge how refactoring affects the quality of the result, if I say "We don't refactor here", and in the Customer generally understands how refactoring generally affects one's capacity to deliver features, then I find it reasonable for the Customer to feel worried about working with us. We have to work harder to earn that Customer's trust. How could it be any other way? The Customer might still invest in working with us, but then we need to retain that trust by delivering in a way that satisfies the Customer. We simply might start from a place of slightly less trust than another group that shows the Customer that they approach design in a way that they already believe creates good results. Again, how could it be any other way?
The questions that you ask in the end really interest me. I have a biased view of the correlation between evolutionary design and producing sustainable designs, because I have been teaching evolutionary design for 15 years now, and so I see more people learning evolutionary design and practising it. I know one significant data point: a bunch of well-trained, highly-skilled programmers who don't practise TDD any more, because they have built an environment in which they don't need it AND they have already learned "enough" from practising TDD, so they have those benefits without the practice. (Search the web for "programmer anarchy" to learn more about them.) I know some of these programmers personally, so I also have some bias in their favor. It tells me that such people can exist.
So I cannot remember meeting a programmer who produces sustainably-maintainable designs who does not practise TDD, but that reflects my life choices more than it reflects the world. Because of this, I can't really answer the second question.