A table can be conceptualized as a data structure or relationship, a type definition. It can also be considered a collection of objects. The former leads to singular names and the latter leads to plural names. It's only a headache if they are mixed.
create table person (
The CREATE statement defines a data structure of which multiple instances can be created. This makes SQL more readable for WHERE clauses and joins, regardless of how many instances are being joined or filtered. Essentially, the queries in the set language SQL can be paraphrased as "server, for the objects of this type, do the following..."
create table people (
This creates a collection of people that effectively have the same, unnamed data structure. Conceptualized this way, queries can be paraphrased, "server, for objects stored in this location, do the following..."
My preference is for the former, because the fact that instances of the same type are stored in the same physical location is only a detail of how most servers are implemented. It is not even true if data are partitioned/sharded across tablespaces or server instances. But, I would not fight it if I walked into a system of the latter.
Oh, and fearless_fool, I don't know if any other systems have this, but Informix has a RESTful API directly to the database entities. While you are correct that is often better to put an abstraction layer between the UI and the storage layer, not all application designs require it. If the database is well normalized, various ways of filtering and combining the entities are really part of the View, and the DB stores the Model. As is often necessary, when requirements change, you can always create a VIEW in the DB to mimic the previous table structure. If this is difficult, you probably didn't normalize your database.
Also, in an object-relational DBMS, you can have type definitions independent of table definitions. In that case, there is less ambiguity about whether the definition is a type or a collection of instances, but most people don't define types separately from tables. When the CREATE TABLE carries both meanings, it's kind of a user-preference.
It looks like the majority of the DB domain decided to think of tables as representing a type of object and most of the REST domain decided to think of entities as being in collections. But, just like you should not be surprised to find snake_case in the DB and pascalCase in JSONs, you should not be surprised that different domains have different conventions.