The data column's meaning changes depending on the value of the type column.

One phrase that comes to mind is "job security". By constructing tricky schemas like the first one, someone makes themselves extra "useful" writing the overly complicated query code necessary to access data correctly, at least until they're taken out and shot by the people who have to maintain and extend the result.

The problem with columns that change their types or meanings depending on other columns (like the type column above) is that complexity gets pushed out in all directions. Anyone who queries the data needs to take on the complexity of deciphering the type field, plus whatever other contortions are necessary to process the data. Standard tools, and standard approaches stop working cleanly. And the more time passes, the more people forget why the poor design was chosen in the first place, which can make it harder to undo the damage.

When I see stuff like this, it's often because someone hasn't gotten over their fear of database JOINs, which can be scary until you've done them a few times. However, JOINs are an essential tool. Trying to avoid them is like being afraid to take off the training wheels on a bicycle.