How does this differ from them building a mountain of cards on top of your API?
The schema used by the public API doesn't have to match the database layout itself. E.g. views can be used for this.
A lot of APIs are quite straightforward mappings typically from REST/GraphQL to a database, often via some sort of ORM or other abstaction. These extra layers mostly amount to needless complexity, more surface of bugs, lots of busywork and worse API usability.
It differs dramatically. Your API is likely much much smaller than the inherent API of SQL tables. It's a difference in degree that is a difference in kind.
I don't see much difference between a set of SQL tables to a set of API endpoints that let you list a set of "objects". At least in read-only cases with no sensitive data.
Of course there's the big difference in that with SQL you can compute and join tables server side, sparing a lot of traffic of doing this manually (or coming up with ad-hoc ways of doing it). It's not like the SQL itself is gonna substantially change.
The schema can be restricted or kept compatible with e.g. views as mentioned before (although I'd go more for the consenting-adults philosophy here too). Too heavy queries can be limited with e.g. query timeouts, quotas or query priorities. And you usually have to do such things somehow anyway.
I have hard time seeing major concrete problems with the approach that don't have existing straightforward solutions. I do see a lot of unfounded FUD.
For writes and sensitive data it gets trickier, but for many cases it would be probably easier to secure the database interface than to do it ad-hoc on a "business layer".
I haven't heard the idea of public facing SQL querying floated around much in at least over 20 years. When it's proposed, the response is usually knee-jerk no, as seen in most comments in this post.
Also I'm not much of a fan of SQL itself but I'm against the current software development philosophy that computing should be made as restricted, layered and inflexible as possible.
The schema used by the public API doesn't have to match the database layout itself. E.g. views can be used for this.
A lot of APIs are quite straightforward mappings typically from REST/GraphQL to a database, often via some sort of ORM or other abstaction. These extra layers mostly amount to needless complexity, more surface of bugs, lots of busywork and worse API usability.