There a multiple reasons why using one large "god table" is bad. I'll try and illustrate the problems with a made up example database. Let's assume you are trying to model sporting events. We will say you want to model games and the teams playing in those games. A design with multiple tables might look like this (this is very simplistic on purpose so don't get caught up in places where more normalization could be applied):
Id | Name | HomeCity
Id | StartsAt | HomeTeamId | AwayTeamId | Location
and a single table database would look like this
Id | TeamName | TeamHomeCity | GameStartsAt | GameHomeTeamId | GameAwayTeamId | Location
First, let's look at making indices on those tables. If I needed an index on the home city for a team, I could add it to the
Teams table or the
TeamsAndGames table pretty easily. Remember that whenever you create an index, that needs to be stored on disk somewhere and updated as rows are added to the table. In the case of the
Teams table this is pretty straightforward. I put in a new team, the database updates the index. But what about for
TeamsAndGames? Well, the same applies from the
Teams example. I add a team, the index gets updated. But it also happens when I add a game! Even though that field will be null for a game, the index still has to be updated and stored on disk for that game anyway. For one index, this doesn't sound too bad. But when you need many indices for the multiple entities crammed into this table, you waste a lot of space storing the indices and a lot of processor time updating them for things where they don't apply.
Second, data consistency. In the case of using two separate tables, I can use foreign keys from the
Games table to the
Teams table to define which teams are playing in a game. And assuming I make the
AwayTeamId columns not nullable, the database will ensure that every game I put in has 2 teams and that those teams exist in my database. But what about the single table scenario? Well, since there are multiple entities in this table, those columns should be nullable (you could make them not nullable and shove garbage data in there, but that is just a horrible idea). If those columns are nullable, the database can no longer guarantee that when you insert a game that it has two teams.
But what if you decide to just go for it anyway? You set up the foreign keys such that those fields point back to another entity in the same table. But now the database will just make sure that those entities exist in the table, not that they are the correct type. You could very easily set
GameHomeTeamId to the ID of another game and the database won't complain at all. If you tried that in the multiple table scenario, the database would throw a fit.
You could try to mitigate these issues by saying "well, we will just make sure we never do that in code". If you are confident in your ability to write bug free code the first time and in your ability to take into account every strange combination of things a user might try, go right ahead. I personally am not confident in my ability to do either of those things, so I'll let the database give me an extra safety net.
(This gets even worse if your design is one where you copy all relevant data between rows instead of using foreign keys. Any spelling / other data inconsistencies will be hard to resolve. How can you tell if "Jon" is a misspelling of "John" or if it was intentional (because they are two separate people)?)
Third, almost every column needs to be nullable or must be filled with either copied or garbage data. A game doesn't need a
TeamHomeCity. So either every game needs some kind of placeholder in there or it needs to be nullable. And if it is nullable, the database will happily take a game with no
TeamName. It will also take a team with no name, even if your business logic says that should never happen.
There are a handful of other reasons why you would want separate tables (including preserving developer sanity). There are even a few reasons why a larger table might be better (denormalization sometimes improves performance). Those scenarios are few and far between (and usually best handled when you have performance metrics to show that that is really the problem, not a missing index or something else).
Finally, develop something that will be easy to maintain. Just because it "works" doesn't mean it's OK. Trying to maintain god tables (like god classes) is a nightmare. You are just setting yourself up for pain later.