Visto il talk.

Sostanzialmente mi trovo d'accordo su gran parte delle cose, anche se come ho detto ho esperienza della questione fino ad un certo punto. Tipicamente, i servizi/le librerie che scriviamo sono abbastanza ad uso interno, anche se, specialmente per cose a cui stiamo mettendo mano ora, abbiamo N client con visioni abbastanza diverse del problema e che vogliono farsi poco i fatti dell'implementazione, per cui parte dei principi che citi emergono in maniera abbastanza naturale.
Un paio dei prodotti di cui parli mi sembrano interessanti e mi riprometto di darci un'occhiata; le specifiche-markdown magiche e il generatore di mock-server possono essere interessanti per roba a cui stiamo mettendo mano in questo momento.

Solo un paio di considerazioni, la prima di carattere generale: onestamente, è un po' sempre la solita pappa del waterfall vs agile e compagnia, con implicito un po' del discorso del capire le esigenze dell'utente (personas, goals, ...) che si usa (o almeno, si dovrebbe usare) in progettazione GUI; tutto vero e tutto giusto, ma alla fine sono un po' sempre gli stessi concetti che girano da "The Pragmatic Programmer" in poi.

Altra cosa: ok il design orientato al consumer della API e non costringere il client a sapere dettagli di implementazione assurdamente precisi (arrivare a leakare i nomi delle tabelle è inscusabile), ma come tutte le astrazioni, inevitabilmente c'è un leak dell'implementazione, se non altro a livello di performance. L'esempio che facevi dello sviluppatore lato client che vuole avere tutto in un'unica richiesta ovviamente regge finché i dati sono gestibili in un'unica richiesta - in altre parole, se ci si inizia a spingere un pelo più in là le API devono comunque tenere conto dei constraint tecnici. A quel punto credo che la soluzione giusta sia fare le API a due livelli, con il livello basso e complicato per quelli a cui servono API ad alte prestazioni e/o per casi d'uso complicati, e quella "facilona" per tutti gli altri (possibilmente una costruita sull'altra).