This would mean that all services, when restarted via this, would automagically have a bigbrotherrc file!
(BTW, we should get rid of webservice2 and merge it into webservice (with symlink from webservice2). Having two scripts with nearly identical names, but different abilities is no fun.)
I don't like the idea of having programs do something unexpected. We have a separation of concerns: webservice starts or stops a webservice, bigbrother ensures that webservices or jobs are restarted if they stop for whatever reason. Having one interfere with the other, especially changing a user-specified configuration file without the user's acknowledgment (or consent), is one of those moments where I as a user at the console don't understand what's happening.
What I would find more appealing is if we rewire webservice (that doesn't survive OOMs) with an SGE epilogue script, i. e. on webservice start a file ~/.webservice is created and the webserver started, on webservice stop the file ~/.webservice is removed and the job deleted, in the epilogue script that is called on job termination it is checked whether ~/.webservice exists, if yes, the termination was unwanted and the script returns 99 to reschedule the job, if no, the termination was wanted and the script returns 0 to delete the job (needs to be tested first). That would have a similar outcome (a webservice start is a long-term statement) without mixing up the two concepts of webservice and bigbrother.