Look at prideout's reply in the thread, the argument about having just one normal vector and the fact they can only describe one plane is huge. Unless you want more edge cases to deal with (hehe, pun intended), you're better off sticking to tris.
Maybe we can continue to describe the geometry in triangles, but could use an additional "virtual fourth handle point" data (maybe expressed in barycentric coords of the other three, so everything is automatically planar) for stretching the interpolation in the expected way.
Anyway, I'm just getting started with Metal, and this provided for a nice theme for experimentation.
This could have been nice ~15 years ago when using much fewer poly counts and relying a lot more on textures for detail was more common. But at the same time, GPUs were also much slower so this approach would be slower too.
So in practice this is really a niche approach for when you want to have a large quad that isn't "perfectly" mapped to an underlying texture and you can't subdivide the quad. Nowadays such use cases are more likely to come from more procedural sides (or perhaps effects) of the engine than artists making assets for the game.
It might be useful for an artist wanting to use a modern engine running on a modern PC to make a low-poly retro-styled game though.
Btw. wouldn't it be possible in modern pipelines to remap or "disfigure" the texture when converting to triangles, so that it counters the bias accordingly? Ah, but that bakes in the shape of the quad, so it can't be modified runtime or it will get distorted again, right.
In the end, the representation of a quad in a 3D modelling editor doesn't really matter. Be it an actual quad or 2 tris. Because any sane artist wants every quad to have 1 normal vec, if they want 2 on a quad they will happily use 2 tris instead.
It is a non issue.
(btw I have done plenty of 3D art for games, I have also made my own vk renderer, I don't see a problem with using tris in the end, even if "visual quads" do de-clutter my work and do help reasoning about the flow of the model at hand)
It's only for tessellation like subdivision surfaces where something like this would be nifty That is to say, this is mainly nifty for the DCC tool renderer itself to render slightly faster.