Well, it could work, but as mentioned by Xynerise there's absolutely no guarantee for it to work. Higher transaction fees does not necessarily mean "skipping the line" if your adversary has also put an adequate transaction fee in place. Problem being that your adversary will have a head start and given a high enough transaction fee has thus a better chance of getting added into a block than your defensive double-spend transaction.
That is well understood, but it at least can give a slight chance to prevent funds being stolen. I actually can pregenerate my transaction and only attach fee as soon as I see malicious tx (if I see it at all), so it surely be higher, therefore raising my chances to save the day.
Furthermore you mentioned that you would trigger this transaction if someone where to withdraw the full address balance. Wouldn't this also prevent your users from accessing their own coins?
Depending on the service architecture - it may or may not be the case. At least I will retain control of the funds. Refunding them to end users is kinda trivial.
You could implement such a bot as an additional safety measure, but it shouldn't be all that you rely on. The safer bet is automatically moving incoming user deposits to cold storage addresses, keeping only a fraction of coins available in a hot wallet for your user to withdraw. For keeping track of the hot wallet a defensive watcher bot may make sense, keeping in mind aforementioned deficits.
It is also worth noting that automating the movement of coins from cold storage to the hot wallet opens additional attack vectors, so be mindful of that, should you choose to add cold storage as part of your security model -- which you definitely should.
I have contemplated defensive measures for quite a while now and cold storage is for sure one of them. My current model is to move 50-60% of all hot wallet contents to cold storage daily, leaving only bare minimum in the automated system (to handle necessary automated withdrawals).
There of course no possibility to automatically refill hot wallet (i.e. production backend have no access to cold storage, it is physically separated systems with proper airgap, and encrypted keys are stored offline, only allowing signing raw transactions that are taken from printed qr codes, which is manually checked before being signed - this sort of paranoia).
The idea I described above is just another layer that in theory could add some extra security to what is left in hot wallet system.