Allora ricapitoliamo:

L'utente fà un'azione sulla tua applicazione che presuppone una persistenza di dati a quanto dici, giusto? La tua riflessione è: "invece di usare la persistenza per mappare i miei oggetti in relative righe/documenti di persistenza, preferisco salvare la rappresentazione di questi oggetti in XML su filesystem e successivamente avere un sistema che prende questi xml, se li parsa, ricrea oggetti, e salva i dati di questi oggetti nel database". Dal punto di vista della sicurezza, cambia poco o niente, perchè a meno che tu non salvi gli xml in una cartella pubblica, un attaccante dovrebbe aver accesso al filesystem del server per leggere i dati che salvi. Certo, se i dati fossero direttamente in un database, l'attaccante dovrebbe bucarti anche o solo il database per leggerli.. insomma, non mi sembra il punto centrale della questione.

Per la procedura in se, invece, non vedo alcun senso pratico o logico: non esistono problemi di affidabilità nell'operazione standard, di sicurezza, di pattern OO che possa portare all'idea di cui sopra. Se dividi l'applicazione in layer, da quello di presentazione a quello più in basso di persistenza, arriverà al fatto che le tue classi di dominio saranno utilizzate dalla persistenza per persistere lo stato di dominio in un determinato istante, senza dover uscire fuori dal "linguaggio di programmazione". Senza poi stare a parlare di quanto sia più complicato scrivere e leggere su file che su database (se utilizzi il file come un "database"), tale passaggio in più rende solo l'applicazione più lenta e a rischio di errori. Anche architetturalmente complichi la cosa:

mentre tradizionalmente te prendi l'oggetto e lo mandi all'entity manager per farlo persistere su db, nel caso dell'xml te prendi l'oggetto e lo serializzi in un file xml. A questo punto, devi schedulare (o hai un demone che gira ogni tot secondo) un job che vada a leggersi tutti gli xml generati in un lasso di tempo, leggerli uno per uno, convertire il dato serializzato in oggetto, chiamare l'entity manager e fargli persistere tale oggetto. L'handling di questi scenari, soprattutto in php, non è proprio banale e può incorrere a tutta una serie di problemi (timeout, troppi dati da elaborare tutti insieme, code di processamento dei dati, etc) che non hai nel caso tradizionale.

Quindi ripeto: se non c'è un motivo più che valido e obbligatorio per fare il passaggio intermedio, introdurre il passaggio intermedio porta solo a problemi, lungaggini, duplicazioni.

Questo se ho ben capito lo scenario che hai descritto te