Basically, AGPL is only useful for a very, very narrow range of software designed specifically for use in "software-as-a-service" situations, and even then, it is only acceptable if you don't need to tie it into existing infrastructure. In short, it is basically never acceptable, and its only sensible use is for businesses to be able to say, "Hey, look, we've open sourced our stack," while simultaneously ensuring that no legitimate business would ever even contemplate replicating that stack and competing with them.
I'll give an example of a use of AGPL. I develop game software with a handful of other devs. I'm the only coder. Prior to game release I license all my contributions under the AGPL so that if I quit, I can take my code with me. However, if they want to sell my code as closed source, they'll need to make it to completion and have me dual license under BSD. At that point we can sell a closed source version of the game software. At any time after sales begin, any member of the dev team can then release the source code as AGPL or BSD. So, there's no "we can't release source without rights holder permissions". We worked that out ahead of time.
In this way I don't have to trust anyone and they don't have to trust me. We do trust each other, but the system is future proof against falling outs (which is frequent in the indie game dev community). No one can just take their ball and go home -- Were I to leave the project I could still use the engine on other projects, and they could still make a game, and get another coder, but the end result would have to be open source. Compliance with AGPL is actually built into the game engine. In addition to containing an archive of the source as an asset during builds, any scripts or mods are necessarily transferred from the server to the client at run-time so that the game can function. A BSD licensed version can simply transfer pre-compiled bytecode instead of textual scripts, and remove the compressed source code from the asset library.
So, here we have a use case that's not exactly aligned with the intended goal of AGPL, unless a goal is to prevent anyone from benefiting from your code without you also benefiting from the additions too. It's actually directly opposite to your claim that I wish to prevent competition, I actually want to ensure competition can exist and ensure no complete loss of effort is possible. Sure, I run the risk of a team member bolting and releasing code under AGPL, but that doesn't prevent us from re-licensing as BSD down the road.
I'd love to release everything open source all the time (and do this for all software that's not game related) but it exponentially increases the number of cheaters in online games (don't give a damn about offline cheats). I've experienced this several times in online game communities, in both directions, closed to open, and open to closed. Until more effective community management systems are in place, games remain unique pieces of software where it's OK to not give users every tool they need to cock-up the game for everyone else (so long as the game respects the end-user, i.e., doesn't have non-features like DRM / spyware). One bad apple spoils the bunch, so griefers affect far more people than themselves. I agree that AGPL isn't the right choice for all projects, but to say it's never applicable except in some narrowly defined scope is just silly; I'm not arrogant enough to make such claims, I'm sure other use cases exist.
P.S. The saying "Security through Obscurity is No Security at all" is utterly false. All security is security through obscurity, and every bit of obscurity counts. 512 bits is 1/2 as secure as 513 bits of obscurity -- Obscurity increases security exponentially, DERP! If the obscurity was no hindrance then "open source" wouldn't even need to exist, eh? It's true that where there's a will, there's a way, so why not require sterner wills to brave harmful ways?