See the jump from 17pt to 18pt? That's wrong. (Also, the small sizes are just completely obliterated IMO.) Font outlines are scalable; they should have the same relative weight no matter what pt/px size you render them at, and they should have the same proportions. Non-scalable rendering is incorrect (although techniques like hinting and gridfitting do intentionally sacrifice scalability for better legibility, but I argue you can do better in most cases.)
Rendering of vector fonts to fixed grid of pixels leads to incorrect results in principle. Introducing blur where there is a sharp edge in vector data is also a wrong result. You can just choose which kind of wrongs is more annoying - whether distortion due to grid-fitting or blur due to naive rendering and antialiasing.
There is no objectively "best" way to render vector typefaces to a raster, but that's not because all of the options are equally correct, it's because options that are more accurate to a font might look subjectively worse. There's nothing "incorrect" that a raster rendering of a shape can't convey the signal with perfect fidelity, but that doesn't mean that all rendering of vectors to raster is equally correct.
Like fine, let's put aside somewhat intentional things like hinting and grid-fitting with accumulating error for a minute. Some FreeType configurations dramatically fuck up the visual weight of fonts, making the regular style in a type face look fairly bold. The damn font looks wrong. It's not "wrong" as in I disagree with what the designers intended for the type face, it's wrong as in it looks nothing like the designers intended and it looks nothing like the parameters you put in to render the font. There is basically no perspective where this output is desired, it's just a bad rendering.
There's definitely a bit of subjectivity in exactly where to draw the line, but there is definitely still a line you can cross that just goes into blatantly wrong territory. The relative visual weight of a glyph is not supposed to be influenced by its size on screen.
Well, because it literally distorts the glyphs and thus doesn't actually look right, it would be like if some of the pixels on your screen were inexplicably the wrong color due to a color management issue. In some cases the distortion is really bad and doesn't even really improve legibility at all, so it's just a plain lose/lose. If you don't give a shit about typography in the least and don't care about the visual weight of text then fine, but not caring doesn't mean the behavior is correct by any means. (And keep in mind, you will often have more than one font size of text on screen at once, so this distortion will change the relative weight of fonts incorrectly, aside from also distorting the actual shape of glyphs.)
But OK, other than just being incorrect, does it matter? Many people don't have proper color management in their software and it's usually fine. Well, yes, sometimes it matters. For one thing, this issue really screwed up scaling in Win32 and even GTK+2, because if you tried to render dialogs with different font sizes it would completely change the UI and screw up some of the component sizing. OK, though, you can fix that by just not using a fixed layout. However, you still run into this problem if you want to render something that actually does have a specific layout. The most obvious example of how this can be a serious problem is something like Microsoft Word that is meant to give you a WYSIWYG view of a document on paper, but the paper is 300+ DPI and the poor screen is only 96 DPI.
Maybe most importantly, this is all pointless! We don't actually have to settle for these concessions for Latin script text on 96 DPI screens. Seriously, we really don't. I recommend this (old) article for a dive into the problems caused by non-scalable font rendering and how it could've probably been solved all along: