It would be easy to attribute this to evil shenanigans and the Satan-Made-Manifest that is facebook policy, but I think it more likely that here you are firmly in the realm of "just so good and no better" incompetent design - the bane of so many modern computer applications.
Ironically, had the design been slightly *less* competent there would be no problem as improperly normalized data wold have disappeared along with the stuff it related too.
Look for more of this sort of thing as "free" database "solutions" that lack the capacity to implement CASCADE ON DELETE constraints (or indeed any FK-type constraints at all) are used to shore up the digital meetingplaces of the virtual world.
But I'm straying into another thread. Sorry.
This sort of nonsense is a hot button topic with me right now as I'm currently dealing with a very popular Document Management system marketed by a Hucking Fuge company famous for its mainframe computers, said DM being unequipped with a single-operation method for dealing with the situation when its meta data doesn't match real life. Apparently, no-one asked what might be best for the owner of this pile of dung in such circumstances at the design stage, something that leaves me breathless with incredulity.
Of course, if a single click solution (AKA forget the missing document FFS) were available, the HFCFFIMC couldn't charge an arm and a leg for a service contract.
And I expect the same kind of "design thinking" was used in the FB "like" logic. No-one actually thought through what to do when you don't like stuff any more, probably because it isn't important to whatever the (doubtlessly evil) core corporate mission of FB is.