I agree with your philosophy: even while making everything seamlessly automatic, maintain the possibility to do it manually. Deprecate functions only if at some point a certain one is not useful anymore.
Personally I like everything as convenient as possible. If software requires me to do something manually, I feel that there needs to be a compelling reason for that. Like WordPress installation asking me the name of my blog, which it can't guess :) If there's no compelling need for a manual step, ie. it could be done automatically, I feel that it should.
I've also thought about how BPS deployment could be more automatic. In any case it would follow basically the same idea as the automatic backup: simplify the steps as much as possible. If the functions of two clicks can be bundled into one, bundle. If an option is practically never used, remove it. If it is used but in a different context, double check if it would be more logical out of the way. For example if deploying default .htaccess files instead of the secure ones is mostly used when uninstalling BPS, the install and setup procedure is most clear and goes smoothest when this options isn't shown as a viable alternative for deploying the safe ones.
The installation system is created with manual possibilities strongly in mind, and I agree with keeping them. However, I would put them a bit aside, as I suspect that something like 90 % of the users look for one-click-security. I imagine the future installation instructions of a secure WordPress to be:
1. Install WordPress
2. Install BPS
3. Activate BPS
4. In BPS settings, click Deploy Secure .htaccess Files
Alternative 4: Click Edit .htaccess Files and after creating your own, click Deploy
Here the default user clicks only once. In comparison, currently the steps are:
4. Create backups of main .htaccess files
5. Create backups of BPS .htaccess files
6. Click to create secure .htaccess files (a separate step from deploying them)
7. Click twice to deploy one of them (select BPS radiobutton instead of Default, then click Activate)
8. Click twice to deploy the second one of them (same as above)
9. Click twice deploy the third one of them (select BPS radiobutton, even while there are no alternatives, then click Activate)
10. Click twice deploy the fourth one of them (same as above)
11. Create backups of main .htaccess files
12. Create backups of BPS .htaccess files
These 9 steps of default setup include 16 clicks, 3 of them for switching tabs, 4 for creating backups, 1 for creating .htaccess files and 8 for deploying them. Automated backups would remove 7 of them and one-click-deployment would remove 7 more.
Both automations will increase clarity of setup as well as convenience, and the one-click-deployment even more so. This is because deployment requires currently a bit more thinking before the user understands that the above steps are what he typically wants.
There's an acronym for this, something like Convenience Over Configuration, but I prefer to use a full sentence to spell out the idea: "If something is the most popular option, make that as convenient as possible." It's like going to a Finnish McDonald's, where you can customize every burger you want, to have a rye bun instead of the wheat one, and so forth. You can, if you want, but because most don't, the employees don't bother you by telling about the option during a normal buying procedure.
Thanks for your efforts in making BPS as good as it already is and for your continued efforts in making it always better. Hope my feedback helps you in this somehow.