They’re non-nominal - you can’t name them in the language being compiled. They work at a finer level than the nominal system the programmer has access to.
That's not really true -- in structural typing, you can name things but the names themselves are just a convenience; an alias for something too long to type without getting lost in it.
Well I don't know then. If you've got a better name for a type that you cannot express in the domain language but can be tracked by the compiler that'll be understandable in a public blog post then I'll use it?
Well...that's still just a type. I never found any reason to name it specially myself, even when I was thinking of similar things that are being described in the article (though not about Ruby, but rather about Lisp-y languages). Maybe I'm a bit influenced by the fact that there isn't such thing as "a type that you cannot express in the domain language" if you have SATISFIES (http://www.lispworks.com/documentation/HyperSpec/Body/t_sati...), but still - a compiler can certainly synthesize "ad-hoc", unnamed types and perform reasoning with them.
By this argument I might as well call everything a 'thing' since everything is still just a thing.
Different names for subclasses of things that already have names is useful.
I get this discussion with people who don't like the word 'transpiler' because they reason it's just another compiler. Yeah nobody's denying that - it's a subclass of compiler with a specific name.
To be fair, "lispy" thinking promoted the notion of closure property in me - just like a list of lists is still a list, a type composed of other types, be it by conjunction or by disjunction, is still a type, and its components are types as well. Uniform treatment seems more logical specifically for programming it into a machine since it eliminates special cases. So I'm tempted to disagree with the assertion that I may need special cases for this.
(I’m not a type theorist though.)