When you hear people saying "if it ain't broke..." it means they're concerned about accidentally making matters worse, not that they're lazy or insufficiently concerned with "continuous improvement".
Sometimes a simple but sub-optimal solution that gets the job done well enough and reliably is better than an optimized solution that includes downtime and requires extra maintenance. I don't think the person offering the advice to leave things alone is always the naïve one.
One thing that really frustrated me when I started my career is that the cost of making changes turns out to be non-trivial. If you're shipping software to customers then making changes to the software involves a lot of work planning testing, packaging and so on. Maybe that's one of the reasons why hosting web apps is so much easier than selling shrink-wrapped software in a box.
I think the position you put forward however is often a mask for fear. People don't like change, particularly when they don't understand what is going on already. It is a sunk-cost fallacy. They invested a bunch of effort in learning the old way, which they didn't fully understand, but apparently it worked, so the accepted it. Now a new way comes along, claiming to be better, but once again, they don't understand it fully, so they just see it as an attack on the way they had been doing stuff -- which in a lot of people's minds translates to an attack on them. When this happens they start justifying "It was fine the old way, I don't see why they had to change it.". Those with some foresight then start saying "if it ain't broken don't fix it" when a change is coming down the pipe. This causes people who can see the benefit of the change to write articles like the one we're commenting on.
There are good reasons why you sometimes really shouldn’t change working systems (you mentioned one), but then you shouldn’t use that phrase and leave it at that. Say something like “Changing the system in the proposed way at this time would be bad because of reasons A, B and C.” or something similar. Don’t take “If it ain’t broke, don’t fix it!” as a self-evident truth.
Too many people create poor first attempts and leave it at that (the example I used was a process which breaks once per month, indicating there is room for improvement that would save Fred time), claiming later "if it ain't broke". I think this is a recipe for disaster because it reflects an attitude that lacks a desire to improve.
However, there are times when it "ain't broken" and it is good enough, and in those situations I agree with other comments that you wouldn't want people wasting time looking to make micro-optimisations. Ultimately I am making the point that people need to have the right attitude toward improvement and quality overall.
Front-end and performance type things benefit more from continual improvement, and "If it ain't broke, don't fix it" isn't as useful.
Does it take some extra effort to reflect on a process and figure out ways to improve it? Of course it does, and that's ok. I take pride in my work, and I like to be surrounded by others that do too. I would rather have to put in that extra effort in an attempt to make something really great, than to go through life leaving a trail of mediocrity in my wake.