Since every field in a database is defined by the combination of table name, column name, primary key and value, you can always reduce the number of tables by denormalizing into a single table that stores just that. Not very useful, but entirely possible.
Tables are a an abstract layer that helps with the issues of dealing with data. That is why they are created. I made it a joke but understanding that you can reduce every set of data to one master table immediately points out why you shouldn't: because tables bring you something.
On a conceptual level they bring you a structure that is easier to understand for humans than serialized data.
On the inbetween level they bring the concept of normalization: to avoid saving redundant data and give a single point for changes, rather than changing something on several places.
On a technical level databases bring most of the things you want to do with data, numerous tools, and implemented them and tested them more than you probably will by yourself. Think of data types, default values, user rights, indices, foreign key constraints etc. It has been tested, used by many, optimized, debugged. (Not into perfection, but still.)
Since a database is a tool, the main thing is deciding how to use the tool. The number of tables are not important. Minimizing is always possible but at the cost of throwing out the benefits. (If you read more about normalization, you'll come across the few cases for denormalizing - but even then it is all about the right decisions rather than just blindly reducing the number of tables.)