I also discovered a major flaw in BLE's crypto that allows an attacker to crack its encryption key and decrypt data, 100% passively. I wrote a tool called crackle that will automatically decrypt encrypted BLE data captured by Ubertooth.
It is more expensive than the sniffer in the article ($120) but very robust. I achieve the requisite frequency agility by handling timing in real-time on the microcontroller on the dongle.
TL;DR: Classic Bluetooth is very secure, BLE is secure under some circumstances. Even if you leave your Bluetooth on in discoverable mode, there isn't much an attacker can do to harm you barring bugs in your Bluetooth stack.
Bluetooth is a well-designed protocol stack that takes security seriously in its design. Implementation quality (and bugs therein) varies from stack to stack. It's always a good idea to disable Bluetooth if you aren't using it, as is the case with any other remotely accessible feature.
Classic Bluetooth has used Secure Simple Pairing (SSP) since 2.1 in 2007. This pairing mechanism is based on ECDH to provide perfect forward secrecy and is highly secure. There was one weakness discovered in the numeric entry pin mode in 2008 by Andrew Lindell. This mode is not commonly used in older devices and more recent devices do not implement it. It's effectively impossible for an attacker to sniff any data sent over Bluetooth with SSP.
In BLE, a passive eavesdropper who is present during pairing can recover the secret key used to encrypt all communications. This effectively makes the security worthless. However, if the attacker is not present during pairing then the encryption is very effective. It uses AES-CCM and doesn't have any major flaws in the design. AES-CCM is used in WPA2-AES; it's well-established and has no major shortcomings.
Finally, some Bluetooth stack implementations have bugs. I've found remote bugs in one major vendor's stack.
When Time Warner did the same thing on my connection, they actually returned the RCODE as NXDOMAIN (implying a failure) along with the A records for the advert page. Resolvers which properly/strictly adhere to the RFC would treat the lookup as a failure, which means that for spam purposes this probably wouldn't have caused an issue. My guess is that web browsers aren't quite as concerned with a strict interpretation of the standards, since they want the users to get to the web site they're looking for under even the strangest of circumstances.
In either case, it's still a shady move by the ISP. At least they provide opt-out, which I guess is better than nothing.
Your code should be more efficient!