I would say that this is cultural decision rather than an objective one. It really doesn't matter that much when you're working alone on a small project that no one's livelihood depends on. But when you're working with people over a long period of time, and there are real stakes to errors or loss of productivity, this becomes an important decision. And in this sense, for a long-term project, I would define 'yourself in 6 months' as a different person.
I would agree that perfectionism as such is bad, but that's almost a tautology, since the word "perfectionism" has negative connotations. The term I'd recommend instead is "pragmatism", which I'd define as such - we want to build our systems in such a manner that will provide the most long-term benefit for the least effort.
This is clearly a tradeoff, and the particular point on this scale which we would consider "pragmatic" will vary strongly between projects. For example, when you're looking to build a web application to quickly capture an emerging market, you should absolutely "move fast and break things", since the benefit from the system depends so strongly on time-to-market, and in any case, the code is likely to be rewritten many times, as you iterate on the product to find that elusive "product-market fit". But on the other hand, if you're coding for a space mission, and you know that any code change after launch, if even possible, would have a non-negligible likelihood of bricking the system and causing a hundred million dollar loss, pragmatism will absolutely lean towards dealing with every single validator issue.
In general, in every project, this should be a conversation between all stakeholders, on "what pragmatism means to us". Or in other words, which types of issues we are willing to live with, and which types of issues are high-risk and likely to cause us more trouble later than the cost of dealing with them early. And then once the decision is made, I would encourage the team to put that into code as linter settings (preferably in a shared pre-commit hook in the source control system). These linter settings would define which types of issues will block a change from being integrated, and which ones are actually ok. And even then, teams can decide to "silence" a particular linter issue, but that would then need to be an explicit decision.
To sum up and circle back to your question, this is the manner in which I would teach this - the value of validator/linter warnings is a cultural issue for a particular team working on a particular project, which aims to pragmatically reduce the risk of project failure and wasted effort, and should be defined as code itself, which can then evolve as the project itself evolves.