why not directly interact with the database table and directly read, write, update values directly on the table rather than the object?
Because in any real-world scenario (or even a moderately sized browser game), you're going to be dealing with many data operations, and you're going to be dealing with a database that's only available over the network.
Note: even if the database is still on the same machine, it's still going to be a performance issue, and it's fairly uncommon to deploy databases and applications to the same machine.
Small data operations are much faster done in-memory, and then you save it to the database once in the end, instead of sending multiple requests.
Let's use an analogous situation. When you wrote this question, you wrote the text locally (in the textbox, in the browser, on your machine), and you only posted it to StackExchange when you were finished.
If we use your "work with the database directly" approach here, instead of having a textbox in your own browser, whenever you press a key you would have to connect to StackExchange, have it register the key you pressed, and then refresh your page (or page content) to reflect that change.
I'm not sure how fast you type, but even a novice typist is going to get stuck on the performance drag that this new system would bring with it.
But if my Class components are the same as my Table columns, isn't a waste of resources?
It's not a waste of resources, it's a minor amount of extra development time which renders you massive performance gains.
The classes exist specifically for the database data to be pulled into memory once, operated on, and then sent back to the database. It's of course also possibly to only fetch, or only write to the database.
Think of it like this:
Corporeal humans (code) and ethereal spirits (database) live on a different plane of existence. Crossing that plane is hard (network performance, query formatting and parsing). If you want to have many and frequent interactions with a spirit, you would have to hold seances (run queries) all the time, which is going to cost you heaps of time and effort (performance).
A smarter idea would be to hold a longer seance once, and use it to bind the spirit (database entry) to a corporeal body (class component) once. From that point on, you can just interact with this corporeal body (class), no seance (network call and query) required. And after your many interactions (data operations), when you're done, you just perform another seance to release the spirit back to his own realm (store the data in the database).
In short, it's not that your approach is impossible, but it does entail prohibitively bad performance.
This thought pattern is very common for beginners.
You are focused more on the effort of developing your code. To you, you'd prefer only writing one thing, not both a table and a class, and since it's technically possible to only write one, you're wondering why you'd ever write two things. That's more work, after all.
But you're missing the bigger picture. In the real world, you tend to be on the hook for supporting the software you release, i.e. what we call ownership. This means that any effort you saved in the beginning, could spell doom for you if it ends up costing you more time during the maintenance phase of the application.
Your shortcut "works" when you only think about the development phase, but it's actually counterproductive when you think about the bigger picture.
Because I like analogies: we're going to have a race. We have to take our car, inflate its tires, and drive to the finish line. Start!
I inflate all four tires, get in the car and take the highway to the finish.
You, on the other hand, decide that inflating three tires takes less effort than inflating four, and therefore why would you ever inflate the fourth tire? After all, it would just mean that the tire inflation process would take even longer. It'd be a waste of resources.
But now you're on the road, and you realize that a car with three inflated tires is not as stable as a car that has four inflated tires. You have to brake more often, you take corners slower, and you can't go on the highway because you can't control your car at those speeds.
In the end, I win because I took the extra time end effort to inflate the fourth tire.
The reason I mention this is because it'd be very good if you learned this lesson early in your career: always remember the bigger picture. A corner cut today may end up biting you tomorrow, and likely more than it benefited you the day before.
Most if not all good practice development entails advocating for taking extra effort (which people instinctively try to avoid) because it surprisingly saves time in the end, and it's the end that matters.