Yes, you can encode it, but you shouldn't have to invent and apply this encoding manually. It's error-prone, it's less efficient, and you lose information.
It's like saying you don't need foreign key constraints as built-in concept as long as you have triggers, because you can encode such integrity checks as triggers. Technically true, but no one is going to buy that is a legitimate argument against foreign key constraints.
I guess what I wanted to say is that there is nothing in the relational model per se that prevents encoding sum types. Of course actual implementations (i.e. SQL) might lack the required syntactic sugar.
I agree, I'm just pointing out that when you have some abstraction X you almost always want to also provide its categorical dual ~X, or you end up having to write awkward encodings to simulate it.
Databases provide product types, and the dual of product types are sum types. As you point out, you can encode this in various ways, but it's not natural and very error-prone.
It's like saying you don't need foreign key constraints as built-in concept as long as you have triggers, because you can encode such integrity checks as triggers. Technically true, but no one is going to buy that is a legitimate argument against foreign key constraints.