Apparently, your question is not about short-circuiting being good or bad in general, but about why VB.NET provides operators with and and without it. With this in mind, the answer to
when is short-circuit evaluation bad?
is simply: when it violates backwards compatibility.
Ok, now you can say VB.NET is not very backwards compatible to old VB6 or VBA, however at least certain parts of the language are. Microsoft's decision of keeping the old AND and OR semantics (without short-circuiting) made a huge category of errors less likely to occur when when porting old VB programs to VB.NET.
On the other hand, VB.NET language designers probably shared your opinion about short-circuiting being a good thing. When I remember correctly, the first VB.NET pre-release versions provided AND or OR operators with short-circuiting, but the developer feedback must have been so bad MS withdraw this decision before VB.NET 1.0 appeared. So the designers decided to implemented it in terms of new keywords ANDALSO
and ORELSE
as a trade-off between backwards compatibility and usefulness.
IMHO this was a good decision. I had to port several older programs in the last decade, and not having to make a heavy impact analysis for every logic expression including AND and/or OR (pun intended) made that task a lot easier and more economic. On the other hand, whenever I have to write a new logical expression in VB.NET, my default choice for the operators are the short-circuit forms, that is what I am used to from C, C++, C# etc, and it allows me to write several idioms in more concise form (even if ANDALSO needs 4 characters more to type).
If you are not convinced, I recommend to read Joel Spolsky's great article about Martian Headsets, which is about why early design decisions in software development cannot be easily revoked after the component or language or API in stake has reached a user base of a certain size.