To be honest, I do not think is necessary but convenient for wikis with a large set of tiddlers. I only used it as it was the recommended method by @valpackett on this post
The plugin drag and drop step exists because the plugins are not exported into the .json.
TiddlyPWA was born specially to be an alternative that didn’t submit a whole .html each time (among other things), as the original blogpost mentions. For what I can understand from Synchronization and Encryption tiddlers and from @valpackett posts, it creates two categories for tiddlers, one with the “app” information (plugins, core, etc), and another as “data”, and then syncs the detected changes from “data” tiddlers into the browser’s IndexedDB (A kind of Cookie Jar on “steroids” that exists on modern browsers) and then upload the changes into the server (anyone with more expertise feel free to correct me ).
What you suggest sounds like a good experiment. Having the wiki on TiddlyDesktop would make it easier to detach the wiki from other browser cache, although I’m not sure how well would play. Maybe we could just drag and drop the “TiddlyPWA” and “Web App Manifest” plugins into a TiddlyDesktop generated wiki and check how well it plays after setting up the sync server(I will try as soon as I have a chance ).
If you refer on what you are currently seeing when the wiki is open then on the browser’s cache.
If you refer to where the TiddlyPWA Sync server is saving the “data” tiddlers, it is doing so into the sqlite3 file inside the hidden .data folder on the project’s root folder.
Last but not least, take all I wrote on this answer with a pinch of salt, as I’m learning how it works myself and I’m highly prone to errors and missunderstadings