Technologically, there is no reason that later classes of bluetooth (2.1 and after) shouldn't be able to be used securely. The 2007 E0 vulnerabilities were addressed in alterations made to the bluetooth spec for 2.1 and later and encryption was made a required portion with alterations made to the pairing process.
Given a secure pairing (which can be verified that the device opens the door) and a proper implementation by the manufacturer or the lock (which uses a secure pin or key pairing process), the lock should be significantly more secure than a typical pin and tumbler.
There are two main sources of concern that I can identify. Both relate to complexity. The main beauty, as well as the main weakness, of a traditional pin and tumbler lock is the simplicity. It is a fool proof and near failproof device because it simply involves lining pins up with the edge of a cylinder, but this also is what allows them to easily be picked.
A bluetooth lock on the other hand is a complex electronic device that has many more parts that can break. A well designed device could be designed to either unlock or remain locked when it fails. For exit from the inside, it should ALWAYS fail by allowing exit, from the outside, it is up to your preference if you would prefer fail as locked or fail as unlocked.
This is largely offset by the fact that electronic locks have been used commercially for many years now with a high degree of reliability, so it isn't a completely new thing. I would recommend that such a lock should have an established standard fallback method of access such as an HID (or similar) proximity card access that could be used to override the bluetooth features in the event of a bluetooth subsystem failure or a failure of your bluetooth device. It could also serve a dual purpose by requiring the proximity card for pairing in order to prevent unauthorized pairing of devices.
The second and bigger weakness would be the further complexity and loss of independence of any externally connected system. If the lock is web connected in to an external service, that external service now may have control over the lock and may be a source of compromise for the system integrity. A decent cryptographic challenge/response is strongly expected to be secure, but a web service providing advanced features has a much higher likelihood of having problems depending on how features are implemented. It adds a huge amount of unknown to the system and I'd be hesitant to use such features unless the standards were well known, published, and perhaps something I could run myself.