I have to say I’m much more fond of mummey’s class then of that shrunk down struct, no offense meant 
also look at the class and the way it structures data, it’s much more flexible then a straight declaration, and could be expanded straight away (with a very simple additions) for quadrivectors, matrices etc. retaining a consistancy of style over the whole math library set.
as for defining a vertex so extensively I wouldn’t know… it’s a bit cumbersome.
defining all that data at once for every vertex.
IE: an explicit normal like that is very unconvenient, what if the model needs to deform? you are going to rewrite the whole vertex for that? if you really want to incorporate it in the vertex definition at least handle it by reference, so that another routine can take care of normal computation and the vertices will always fish the right normals even when those are modified.
also, are there any particular advantages in defining the texture coordinates directly in the vertex?
I can see that going wrong in a number of occasions.
to avoid data redundancy you won’t define each single tri/poly repeating overlapping vertices everytime, you’d be better off with a lookup for a point cloud where shared vertices only take one slot and then another lookup takes care of binding texture space samples to vertices, therefore you declare the UVs in the samples data and look them up, not straight away in the 3D space vertices.
also this kind of handling allows to see if you need to shade continuously or not just looking at the point cloud (overlapping double entries mean the points aren’t merged).
dunno, maybe I’m thinking too much in terms of plugins and dev for 3D apps, while you think in different terms that come from a different school of thought.
where I come from you don’t always need/use all those info about vertices, so this style (including its baked normals) doesn’t make much sense to me.