.... just a few thoughts ...
1. Changing the password algorithm makes updates to a new WB version impossible as you cannot restore the passwords to encrypt em again.
Agreed.
But that's nothing new. Every system after having its access algorithms changed, have to allow users to login somehow.
Mostly by resetting all user pass, and sending a step by step procedure to change pass.
2. To use rainbow tables you need access to the WB database , if you have access to the database tables , you simply reset passwords to a value you like. No rainbowtables needed at all.
Getting a dbase = getting all datas along with passwords pretty easy, and fast, if they are are encrypted only with md5.
Except if they are somehow encrypted/decrypted also with 3rd party tools (aes256?)
Can't remind myself an opensource content management solution with such feature.
From the other hand there are also so called "pass hash attacks".
But you mentioned about blocking connections in further part of reply.
3. Adding a salt is questionable too, as if someone gets acces to the database to read the hashes , he does not need to hack the hashes anymore (see above) and having the salt stored in the same DB makes it even more worthless.
As I mentioned above.
4. If i plan to attack a CMS site i would first try to figure out some usernames , after that i would go and set a bot to test the 500 most used passwords against that accounts , chances are very good that you succeed. 
hehe
We all know that users are the weakest links in all IT systems

5. Don't dream , write a replacement for WB registration. Just a few additional filters and you are done.
Kingdom for the one, who understands regular expressions, and could teach me them :/
I have to stay with my dreams...

6. Allowing spaces does not help much, its just one additional charakter to take care off.
Not exactly.
Normal users tend to use dictionary, easy to remember passwords.
If they were able to use a sentence-like passwords, consist of 3 words, this would make very difficult to break the password, as solution in your 4th point won't handle it

And it's not about replacing spaces with dashes, or using whole sentence as a 1 long string.
7. One really usefull thing to slow down brute force or dictionary attacks to your website is to slow down the login process if someone entered a wrong password. If you wait 10 Seconds to say "hey, wrong password " most attacks would take a really long time.
Fully agreed.
Users won't correct their pass faster than within couple (3-5) seconds.
Haven't go deeply in WB's functions, but is there anything more than blocking login access with a cookie/session ?
What about automatic attempts ?
8. Slowing down the login whith 10000 times hashing a string is plain silly It fully eats up your Server resources fo no gain in security . Simply use sleep() in combination whith an IP block.
Combined methods are the way to go.
IP block isn't imo a reliable solution, although attacks tend to come from 1 machine/network.
Other thing are server security options, and protection from resource overloading.
That's what cms can't handle/protect fully on its own.
ps. what sort of nerd would hash passwords using e.g. 50x loop with sha algorithm ?
This wouldn't make any sense, as attacks based generating identical hashes came tru last year (or 2?).
But they still take too much time to be efficient

9. Multiple hashing makes the use of rainbow tables a lot harder and slows down brute force on the hash, but again if an attacker managed to get that far you are lost anyway . This still makes a lot of sense if you are protecting the password file on your server.
50 x sha1.salt.timestamp loop ?

10. Ensuring save passwords is good, but do not overdo it or you users will kill you (customers maybe simply go away) or start storing their paswords in their browsers.
I know the problem. 1 special character in the password makes them too complicated in most of cases.
Real pain to maintain user pass security.
11. As a result of the things mentioned before fixing security issues that let you access sensitive parts like user management or MYSQL DB are first priority.
Making small steps is always a good approach.
Wait, wasn't it about humanity ?

Anyway I don't know about all vulnerabilities of WB. Just pointed the thing with passwords stored as a simple md5 hash.
As a sidenote quite many systems hold pass in plain text. But their protection bases on other levels of accessing the data.
Don't know much about such methods. I was just curious why novadays some biggest players in interwebz still holds user passwords in plain text format.
12. WB only uses Salt in its FTAN /IDKEY system for now , but all security systems will undergo a complete rework step by step.
That would be a nice changelog entry.
Forgot to add, that some "scientists" are testing a method of drawing password images.
I've seen a similar method used in captcha, where drawn picture has to have a minimum 5% diffraction, to detect bots
