From my perspective, the entire point of this feature is to allow
applications to use "the system Tor" (or, at least "some already-running tor") to put their hidden services on.
(Or, looking at it another way, if you don't want to share a tor instance with other applications, you can do that easily today -- you start up a tor, and can use __OwningControllerProcess as you see fit).
The *only* reason that txtorcon by default launches a new tor process for the "onion:" endpoints is because nothing else will work reliably.
I'd very much like the default to be that it adds a new onion using Yawning's API. This will still fall back to "launch a new tor process", but if you know what you're doing you can have a system (or personal) Tor instance running (with cookie authentication) that can have hidden services added and removed from it.
Obviously, this will be a lot faster than launching a new Tor (and less load or DirAuths). As a bonus, Yawning's API is nice and simple (versus SETCONF, which makes it super easy to nuke all the *other* hidden services you configured).
What I would expect of people using this feature is that the process that's "adding the hidden service" is the very same one that's "providing the service"...
(If you're doing something with a separate nginx or whatever process running your hidden-service, than you should know enough to be able to add a couple lines to your torrc and make a normal, "permanent" hidden-service).
So, in that context, if your application code isn't perfect and might sometimes crash, definitely the right thing is to nuke the hidden service. If the app didn't even save its private keys before that happened, well, too bad.
I guess to put another way: I can't see a use-case to keep the hidden- service around if the application that added it went away.