Do you mean it is useless for security, bugs or both?
And the version covering everything on stack is quite expensive. Which is why there is stack-protector-most now.
ASAN is great at detecting many unintentional memory errors, but it's not designed to thwart malicious attacks.
If you need a specific example of ASAN binary being exploited then see: http://int3pids.blogspot.ch/2015/04/confidence-2015-teaser-q...
Why? stack protector prevents overwriting returns and it works. It won't stop overwriting data and that's known. Would you turn it off when compiling anything?
It introduces vulnerabilities, it's a lot of complex code that wasn't written with hardening in mind, it defeats ASLR, and there are many memory errors it can't detect (which an attacker can use to bypass the checks if they suspect you are using ASAN).
If you want to "harden" your code against an attacker who doesn't know what they are doing then it might help. If you want to stop attacks by somebody skilled then enabling it is making you less secure.
Heck, there is no good debug malloc style library mentioned either plus flags to disable malloc optimizations present in the GCC.