Someone constructs an ill-conditioned situation and then uses it to prove that a certain package has limitations. To me this sounds a bit like the Maple-Mma comparisons that are occasionally pilfered on the web in order to demonstrate the superiority of one over the other.
In this case, I do not believe the example says much about the quality of DirectSearch, or the other tools in Maple. If faced with an exponent of 100 in a real situation I would not even dream of using any package in a direct straightforward application. Axel gets my vote here: first bring your problem into a form amenable to a solution. If that is not possible, you are likely up to no good in the sense that the underlying problem may just be too ill-conditioned to be amenable to a solution. And granted, I see this from a physicists perspective, meaning that in my world there would usually be some underlying physics or engineering problem. If the problem is ill-conditioned, likely any solution would not be very stable in practice.
Personally, I prefer to use Maple's build-in facilities (solve and fsolve for solution, the various fiting modules for linear and nonlinear fits). Do they have limitations: you bet they do. Can one work around those: in a surprising number of cases: yes. What do I do if Maple's modules do not succeed: I go back to my problem reviewing what I am actually trying to do here. I have dabbled with DirectSearch but not seriously used it, but in the cases where I tried it its results were not out of line with the ones I found using Maple's modules. In that sense I don't think DirectSearch is any worse; and I can believe that it will solve problems that Maple's modules have a hard time with.
But finding roots involving powers of 100 using numerical methods... well, I have a hard time with that no matter what they are called and who programmed them. And it certainly does not disqualify a software routine if it can't do that without a lot of hand-holding.
Just my $0.02