While I don't disagree with your points, there is still ground to be made here.
1) If designers had a "tailwind linter" in their design tool from the start, I believe that they would be encouraged to use it from the start and would start tweaking their designs from the get go to look just as good with it.
The same principle applies to code linters. There are exceptions where developers can disable a linter for specific pieces of code, but having it there encourages the code to be "constrained" in a consistent way.
2) Just because a design has a "13px" padding doesn't imply the designer thought "13 pixels is the best value here and 12 pixels is simply unacceptable". A design linter would help with the "expressiveness" of the design and when things truly are "exceptional" cases.
Note 2: I'm obviously recommending a technical solution to the problem very early in the design process, but the way I solve it now is by discussing it with the designer over a zoom call. I'll show them the design and say "does this look good? I deviated a bit, is that ok?" It almost always is, which is a win for everyone.
Basically, we're asking workaday designers to design using a tool that doesn't respect the implementation constraints, and doesn't allow them to preview at arbitrary window sizes.
Many designers I have known think of consistency in terms of branding (at most). There is almost always some weird edge case that means a new font size, or unique spacing. Get enough of those, and the design system falls apart.
Some are better than others at this, obviously, but the mix has not really been in consistency's favor (though I will admit it has been improving the past few years).