There are a few benefits to this approach. First, this allows you to start a project with a comparatively simple document-oriented API that lends itself to many use cases in terms of modern web applications.
While you get this with your usual NoSQL, document-oriented databases as well, BedquiltDB sports the additional upside of being able to draw upon all the features of a SQL database like constraints and transactions. Moreover, it allows to gradually transition from a no-schema (or loose schema), NoSQL approach to a strict schema, SQL / RDBMS one if required without having to change the underlying database technology, which is a pretty powerful selling point in my opinion.
I really like the idea of more or less automatically providing a simply API on top of a SQL database. Software like PostgREST or my very own ZenQuery allows you to easily create REST API endpoints for existing SQL database tables. This saves a lot of boilerplate code and repetitive work that usually comes with with creating CRUD web applications.
A fine example of how this can be put to work is Ng-admin + PostgRest, which allows you to easily create a fully-fledged admin interface for an SQL database.