Create a variable which lets (or not) to edit the list of forbidden forms and provide an UI for editing it

Yes, it is now "protected" by "Forbidden forms" recipe book, which is created for "protection against protection".
Let me explain why user_login form has become forbidden. If some enabled recipe appears to be broken, then fixing it becomes a critical issue, since you have no chance to log in again once you logged out. We should have no protection at all on such forms (like user_login, user_login_block and update_script_selection_form that are all in forbidden_forms currently) rather than being in a situation of a permanent force-major.
Please give a use case of login form protection: why do you need it? User_register form is protected as usually - no exceptions. But why to protect login form? If a spam bot does not have an account, it couldn't log in in any case, right? And if it has - you should ban the user.
Let me know if I misunderstand something. Feel free to reopen the issue in that case.

I'd implement something like a botcha_disable variable that can be set to TRUE in settings.php in order to get back in. Force the user to put botcha_disable=FALSE into their settings.php before they can enable BOTCHA on the critical forms.

Or by variable_set. That is interesting in any case. Let's turn it into feature request.

The importance of problem of getting back in (i.e. disabling Botcha on login forms) will fade when all recipes are fully debugged.

Having it disabled at all times is not a good decision as there are spammers that use humans to create accounts but then pass the accounts to the scripts. Therefore we need to have options available to protect any form on spammers path - register, login, post content.

Said that, it appear to me a simple setting in the settings.php should be sufficient> It can either be a setting that lists all forms to disable Botcha (override Botcha settings), or boolean "enable the disable feature of Botcha" or whatever name can suit better (I think "unprotect login forms").

Some words about what has been done.

• Added hidden setting botcha_enabled_[form_id] which allows to configure BOTCHA protection by settings.php tuning.
• Added form disabling feature.
• Added "form combiner". It provides 2 interfaces of editing (individual and multiple) while the implementation of each form editing remains the same. In other words we need only one test for both ways.

And also:

• All admin paths are unified by Botcha::BOTCHA_ADMIN_PATH constant.
• Refactored admin links appliance. Now it is a responsibility of BotchaForm class, no more BotchaRecipebook. That lets us to improve code readability and remove some workarounds.

Fixed in D7: http://drupalcode.org/project/botcha.git/commit/d203d60.

Additional bugfix for D7.

Finally for D6.

Fixed for D6 as well: http://drupalcode.org/project/botcha.git/commit/65830a9.