It could be the case that the two tables represent two independent instantiations of a single or very similar concept. One might be a list of chefs and their DO

It could be the case that the two tables represent two independent instantiations of a single or very similar concept. One might be a list of chefs and their DOBs, and another a list of robots and their manufacture date, and for whatever reason you want to see if both of them are identical. There's no reason to unify both into a single table if your data model doesn't presuppose any correlation between chefs and robots, but someone might want to see if all their chefs are robots and if all their robots work as chefs. Obviously it's a contrived example, but my point is that there exist cases where having two tables with the same columns makes sense, if they store unrelated data. That the data is unrelated doesn't mean that the tables cannot contain identical data, it just means that they don't necessarily contain identical data.