Better would have been to show multiple, similar, validation procedures and then the DRY version, at least that would have been an appropriate use of the DRY principle. But even then, marshaling and unmarshaling the data like that is bordering on moronic. Generic, yes, but still bad code. Certainly unsuitable for any tight loops, and it only contains one notion of validation (is data present). It does not handle the case where the empty string may be a valid value. It does not include any kind of invariant checks (if foo.X in A then foo.Y in f(A), 1 < foo.Z < 1000, etc.). Once your validation routines include those, it'll become obvious that there is no good generic validation routine and having one validation routine per structure is DRY.
The other problem with a DRY method is that you often increase cyclomatic complexity. Where each single method has one execution path (6 paths in total) the DRY method has 6 slightly different intentional execution paths, but 2^6 possible paths, this can make reasoning about the method impossible.
KISS first design seems to assume you will know the whole codebase, and you just shouldn't write anything too big for that.
Also, KISS people will tell you 100 lines of code are better than 2 mega frameworks. But you might only need 50 lines if you had those two frameworks. Your complexity has gone up maybe 10 times, but your performance is better and your readability is way better because.... there's less to read.
How Vue does it's thing is not my problem. I don't care how complicated it is.