bcrypt is a hashing algorithm for securely hashing passwords, this is something you want to be slow, yes.
However, the discussion in the link is about encryption, which you want to be fast. A popular webserver serving HTTPS to thousands of clients can't afford a 10x overhead on the speed of encryption.
Encryption and decryption speeds need not be symmetric. Salted passwords are a stereotypical example... Lets say my password is "password" and I salt it with a random 8 bit value to make rainbow tables 256 times longer than unsalted. I can encrypt the salted password in one round.
However on the decrypt side a salty password is going to have to average 128 rounds before a match and a worst case failure / non-match means you have to run ALL 256 rounds just to make sure.
Obviously we're talking salty passwords not secure web traffic, but the point is off the shelf systems have existed for decades where the decrypt system is orders of magnitude more expensive than the encrypt system. Implementing an algo with those characteristics for web traffic "superficially seems feasible" although the details are fuzzy.
As an example of a rough guess, 16 bits of salt would scale pretty well for "thousands of clients" if the server and client are more or less similar performance level (which within an order of magnitude or two is probably about right). Simple salt is the wrong algo for this job, but...
bcrypt is actually a cipher, like standard blowfish but with a much more expensive key expansion function.
When you call the bcrypt "hash function", what it is really doing is performing this key expansion then using the resulting key to encrypt a constant string.
GP is right - you can use bcrypt as a regular cipher, and the extended key schedule will make brute-forcing harder.
It is inefficient and unnecessary though - a 384-bit key will not be attacked by brute force anyway, and blowfish's small block size of 64 bits can be problematic (you need to change the key quite frequently to prevent active attacks.)
There are a lot of applications where we want encryption to be faster. The slowness of SSL delayed its widespread adoption until _very_ recently, and is still delaying it, for instance. And ciphers are often much faster on dedicated hardware (which a good attacker will have) than in software on a general-purpose chip.
It's better to make brute-force attacks infeasible by increasing the search space than by making each individual encryption take longer.
