ti porto un altro esempio, ho fatto un'applicazione che gestisce le commesse per un'azienda, nel dettaglio: possibilità di registrare-modificare un utente, assegnare commesse all'utente, l'utente può inserire note di avanzamento, files, ecc.; una parte di utenti dediti ad attività di un certo tipo devono interagire costantemente tra loro usano una griglia dati in modifica continua e vedono la situazione costantemente aggiornata.

Architettura:
storage Azure Table
parte client diverse app in Angular per autenticazione, login, dati
parte server Net Core, diverse api per autenticazione, dati
piattaforma Cloud Azure
gestione di alcuni microservizi in Azure Functions, gestione dati realtime con signalR

Come vedi i dati di progetto iniziali sono mediamente complessi e per visualizzarli supponiamo in una griglia dovrò fare diverse chiamate

Se volessi ancora per esempio ottenere tutti gli ordini di un cliente e paginarli a video come faccio?

supponiamo che in Table Utenti ci sia (è solo un esempio, sto banalizzando...)
PartitionKey RowKey Nome ...
user pippo@email pippo
user pluto@email pluto
admin ziopaperone@email ziopaperone

e nella Table Dati ci sia
PartitionKey RowKey Dato1
101 pippo@email abc

uso la mail dell'utente come id univoco, quando è autenticato ho quel dato
l'utente vuole vedere le sue commesse: eseguo una query con chiave RowKey sui Dati
e via dicendo; se devo interagire con più tabelle dovrò trovare una chiave apposita, anche dopo ogni chiamata.
Come posso eseguire questo lavoro? anche qui dipende da scelte personali, puoi predisporre delle api di base e poi collegare i dati con chiamate a 'cascata lato client
this.httpClient.get(..).subscribe(x=>{...});
oppure lato client chiamare solo un'api che elabora già una parte di dati, magari appoggiandosi ad un BusinessLayer apposito

In un modello relazionale ordine ha la foreign key a cliente quindi la prossima volta che recupero i dati di ordine troverò quelli del cliente aggiornati

in Azure Table non hai foreignKey, ma è comunque uno storage semistrutturato, per cui hai due chiavi PartitionKey e RowKey con caratteristiche ed utilizzi particolari indicati nella documentazione; con quelle due chiavi incroci i dati ad es. come sopra tramite query.
Altri storage potrebbero avere caratteristiche differenti, qui ti porto l'esempio di Azure Table perché lo uso da parecchio tempo

Il vantaggio di archiviare dati con forma diversa senza definirla è indubbiamente potente ma quale poi il prezzo di gestire tutta la logica nel codice?

per me è un vantaggio enorme, se penso a quante volte mi hanno fatto cambiare struttura....
almeno ora se cambio struttura di un model la cambio a codice sulla parte client e server, ma non ho casini a storage o perlomeno li posso gestire meglio.
Con una struttura come quella sopra ho inoltre tutto disacoppiato, un altro vantaggio.
il prezzo è nel cambio di mentalità, nel tempo di apprendere una cosa nuova, forse si lavora un po' di più a codice ma non ne sono tanto sicuro; personalmente è stata una scelta vincente, un mezzo in più a disposizione, ovviamente valuto progetto per progetto se usarla.

Un DataAccess su questi sistemi che gestisce dati di questo tipo che "forma ha"? Come recupera o salva i dati in transazione?

E' uno storage semistrutturato, ogni Table ha due chiavi, ha una proprietà Timestamp, il resto delle proprietà ci metti cosa ti occorre, potrebbero essere le stesse per ogni riga.. oppure no!
Per le altre caratteristiche leggi la doc, puoi comunque gestire le transazioni.

ciao