Ciao,
tenderei ad escludere il solo client diretto verso il db, più che altro per evitare di amministrare con utenze il DB stesso, a meno che non ti trovi meglio come DBAmministrator, ma ho paura che la sicurezza del DB potrebbe essere a rischio.

Escluderei anche la cartella condivisa, non mi pare una soluzione molto professionale, anche perché in ogni caso sarebbe grossomodo lo stesso discorso del solo client diretto nel db.

Credo che la soluzione migliore sia proprio la prima, ovviamente il server deve essere in esecuzione quando si inviano i dati, a meno che non si prevede una memoria "temporanea" sul client stesso, che di tanto in tanto proverà a collegarsi per vedere se è possibile scaricare i dati dalla memoria temporanea del client a quella fissa del server. Ovviamente userei i web services, così se un domani voglio accedere ai dati da altre applicazioni (da web, o da smartphone ecc.) lo posso fare sfruttando ciò che ho già.

Tra l'altro la reattività di una applicazione WPF o Windows Form ovviamente non è paragonabile ad una applicazione web, ma farla web ti risolverebbe il problema della distribuzione. Magari cercherei una buona via di mezzo, ovvero Silverligth, perché con javascript e HTML5 si lavora bene (SPA o comunque client in javascript), ma non quanto Silverligth, senza considerare che lavori anche lato client con .NET. Però non va bene se serve la compatibilità con il browser dei tablet/smartphone ecc., infatti Silverlight non è compatibile con quest'ultimi, dovresti scrivere app native (se usi app native per Windows Phone avresti già gran parte del lavoro fatto da SL).