Well, bcrypt + random salt is great but it still can't protect you from bad passwords. It's vulnerable to a dictionary or bruteforce attack the same way everything else is.
You _can_ increase the difficulty of bcrypt, which essentially increases the iterations (as you mentioned). Most bcrypt libraries default this value, but the programmer can override it. The downside is that this requires you to update all of your hashes, which limits how often this is done.
Note: if your hashing algorithm is too compute intensive, you have to take other measures to prevent your login system from being a DDOS vector... for example, with SCrypt's recommended defaults for passwords, the .Net library takes almost half a second of time on a modern CPU... if you get more than a few dozen requests per second, per system you can be brought to a crawl without other mitigation in place.
I would avoid slow implementations of password hashing algorithms. You want the overall operation to be slow due to the computations you're performing, but you want the implementations of those operations to be fast. Because the attacker's implementations of those operations will be fast.
I didn't compare to the C/C++ implementation, it was harder to get that working on windows... I did compare to a JS implementation[0] running in node, which was about half as fast though... mainly because at the time many node modules requiring a build step didn't run well in windows, and my target environment was windows.
You _can_ increase the difficulty of bcrypt, which essentially increases the iterations (as you mentioned). Most bcrypt libraries default this value, but the programmer can override it. The downside is that this requires you to update all of your hashes, which limits how often this is done.