TL;DR
The reason why they're bad is listed in the links you've provided. Due to how the Windows OS is designed, the way the functions were coded, and the fact that determining if memory is valid is hard makes these functions inherently unstable to use.
There is no good way to determine if a pointer is using a valid part of memory. Freed memory doesn't necessarily get zeroed out or reset. If there is a bad pointer floating around it could point to data that in a valid portion of memory. Just because you can dereference the pointer doesn't mean that the data itself is valid.
Those two functions use page guard exceptions to determine if the memory is valid. The design of these exceptions is not supposed to be used as a "valid memory address" check. As described by the first link:
The IsBadXxxPtr function will catch the exception and return “not a
valid pointer”. But guard page exceptions are raised only once. You
just blew your one chance. When the code that is managing the guard
page accesses the memory for what it thinks is the first time (but is
really the second), it won’t get the guard page exception but will
instead get a normal access violation
Basically even by using these functions you can cause access violations because of the overall design of the Windows OS, and how these functions were coded. Even if you're not using page guards there's no guarantee that other shared libraries that you're loading aren't using page guards.
Trying to catch exceptions from the OS that are trying to tell you that things have gone terribly wrong is a bad idea. There is a programming error somewhere and the best option is to crash. Trying to return to a good state when things go that wrong can cause undetermined behavior.
The bottom line is you can't fix what went wrong with memory. Continuing execution will only burn you later.
