Why is the Subscriber support not working for me?
We use this feature extensively, and it is solidly reliable. Try checking your browser settings, clearing the cache, etc, the usual things that you should do when using salesforce.com. Assuming you are security-reviewed, you should be able to obtain logs normally through the Developer Console.
What will this extra permission allow me to do? What can I see without it?
This permission isn't documented anywhere that I could find, so it's probably an undocumented feature (this sounds redundant, but some features are documented, just hard to find). From the description of it, it sounds like the feature will allow an organization to obtain the logs from managed code (instead of just seeing "ENTERING_MANAGED_CODE" ... "EXITING_MANAGED_CODE" lines, they can see everything between).
It doesn't grant you any extra permission. It grants your client the ability to obtain debug logs for your managed code (thus exposing your IP to the client). This would be necessary for code that you can't run under your own context. For example, you can schedule a class, but that class would run in the user's context, not your own "Subscriber" context (which exposes your managed code logs). Also, the Debug Logs setting runs in the org user's context and not the Subscriber context, so using this logger requires the permission. The Developer Console should always expose your managed code for you, including asynchronous calls and API calls made while your console is open.
Why do I need to enable it per customer and not for my ISV package?
Why is this only temporarily activated by Salesforce?
I think I've already answered this by the previous answer, but in case it's not clear, if this feature were tied to your package, /all/ of your clients would be able to debug your code, not just the one having problems. This exposes your Intellectual Property (one of the primary reasons for having the package managed to begin with), and bloats their log files with code that they shouldn't need to see. This feature would also degrade their performance slightly, since logging takes up CPU time. Like the Creatable Audit Fields permission, it's more of a hack than a feature, and meant to be used only if absolutely necessary.
What is an efficient, repeatable way to pinpoint errors in managed batches in customer orgs??**
You should be able to use the Developer Console; it should "reliably" work. Furthermore, as long as "Notify Apex User" is set, you should also get emails when something breaks. While this is somewhat dodgy (it doesn't always get to you), make sure that setting is correct.