Nobody including DJB has proved that Brainpool curves are not safe. The only relative weakness that has been mentioned in the safe curves wiki was related to twist security, which includes according to this wiki things like "invalid curves", but those are more implementations issues than something attributed to a curve's properties, e.g. if you always validate point-on-curve condition in your protocol, "invalid curve" attack won't be possible.
Unlike in NIST case, Brainpool's constant generation method is clearly defined and doesn't leave any room for manipulations. In NIST case a method of a seed generation has never been disclosed, which has made some people (including me) nervous after DUAL_EC_DRBG exploit had been disclosed.
The disadvantage of Brainpool curves compare to the NIST ones is that the former couldn't be optimized, which makes them about two times slower than the optimized implementation of NIST's curves, but peace of mind is more important than optimization here.
In regard of DJB's "safe curves", an apparent disadvantage is that a group of researchers that work with them is smaller than that for more traditional curves defined by the short Weierstrass equation. It means that declared "safety" might not live too long as more researchers start looking at them in details.
Bottom line, you should be perfectly safe with Brainpool curves and they are in the short Weierstrass form, which is what you're looking for.
Check this one as well. It's related to "safe"/"not safe" discussion. A timing attack on Curve25519 is described there. It's based on a flaw in a EC point multiplication implementation, so the curve creators could say that it's an implementation problem. At the same time, they claim that other curves are not safe because it's very difficult to implement them right. Well, judging from the provided link implementing Curve25519 right is not easy either :)