I've worked a lot with tables that store a more generic "object" type thing, so the rows in the table are mostly defined by relationships with other rows in that same table... and it does have its advantages. But it can also be a royal pain in the rump debugging problems.
If you have no real compelling reason to organize the data this way, for clarity's sake I would create separate tables for each object type.
When it comes to speed of data access, your two examples don't make sense to me. One is a union and one is a join, but wouldn't your different object types interact with one another in the same ways (either unioned or joined) regardless of which design you chose? If I'm right then the real question should be: Is joining a table to itself faster or slower than joining two different tables? And my answer is... I dunno... set up tests of both scenarios and find out.