Impedance mismatch happens often when directly mapping table's data to an object. When working with an API that match perfectly a database table, the user will have 2 choices (inside his client's applications):

1) Building an object from the data received from a REST call (which is the same as mapping a table's data to an object).

2) Create 1 or multiple REST calls to the API, transform the data and creates an object.

The chances that #1 happens is far greater... since #2 is normally done when building an endpoint (Object) RESTful API. So, if you would do #2, it might be a better idea to create an endpoint API and comsume it in all your client's applications...

If you do #1, your client's applications will be exposed to impedance mismatch.

I don't see how these problems from the object oriented paradigm necessarily translate to this tool. It assumes a lot about how one plans to use their REST API.

Why would you map your REST API to tables and not views (or stored procedures)? When would you ever want to have tables interfacing with your application unless you're doing something absurdly under-/de-normalized?