I will put it back in the next time I do a release, but I am not worried about this attack.
On my machine the difference between comparing the same-length 60-character strings that are equal in the beginning, versus the same all the way to the middle, versus equal, is less than 10 nanoseconds. This article suggests an attacker may be able to resolve 15ns differences by taking 9,000 samples from a great network vantage point. These 9,000 samples invoke the very slow 71 millisecond bcrypt function. A successful timing attack will peg your CPU for hours or days.
Now consider the attack: generate a bcrypt hash that has a common prefix with a stored password hash, and use timing differences to lengthen the prefix by guessing when the next character is correct. Since any change to the input (the guessed password) will change about half the bits in the hash the attacker cannot generate hashes that have successively longer common prefixes without doing an extremely time consuming brute force search. The work done to find the shorter prefix is useless for finding the next character.
If your application allows a user to attempt to log in an unlimited amount of times at a very fast rate then a dictionary attack is more likely.
Sorry but how is this resolved? cryptacular offers an API to compare the hashes and it's not using a constant-time compare. If you want people to use hmac.compare_digest then fine, but in that case you should remove / deprecate the API that is doing a non-constant time compare or update the _cmp function to use hmac.compare_digest internally.