Recently I've found out on this website that brainpoolP256t1 and brainpoolP384t1 aren't secure.
Actually, that website doesn't say that, it says they aren't safe, where their definition of "safe" means it meets all of a series of requirements.
If you go through the table they give, brainpoolP384t1 fails the safe requirements at three points:
ladder; there is a fairly simple algorithm for doing point multiplication for certain curves; this algorithm is moderately fast, and also tends to be resistant to timing and cache-based side channel attacks (but not DPA-style attacks); that algorithm as listed doesn't work for brainpoolP384t1 (actually, it does, it's just a bit more complicated). One can certainly make the case for simplicity; however just because a curve doesn't implement it as easily as others doesn't necessarily mean that the curve can't be implemented securely.
complete; does the curve allow the implementation of a point addition algorithm that works without branches in all cases (point doubling, adding the neutral element); brainpoolP384t1 does not (at least, not without complicating the algorithm). However, some point multiplication algorithms don't require unified addition/doubling algorithms and avoid the neutral element; again, simplicity is a good goal, however just because a curve doesn't allow this specific simplification doesn't mean that it's not secure.
indistinguishability; is the representation of a point distinguishable from random; for brainpoolP384t1, it is. On the other hand, unless you're implementing a PAKE, that's usually not important (and even with PAKE, there are ways around it), and a curve can not implement this, and still be considered secure.
I believe that brainpoolP512r1 has the same properties, and so this page needn't be considered evidence that it isn't secure.
As for whether it is secure, well, the best I can say is "there's no known cryptanalytic result suggesting that it is not" (which is ultimately the best we can say about most cryptographic algorithms).
When I'm using brainpool, my public keys encoded in base64 have around 210 chars, but for curve25519, they expand into 410 chars which causes a few problems.
Now, that sounds odd; a curve25519 ECDH and EdDSA (you can't use standard ECDSA with curve25519, at least, not with the ladder algorithm) have public keys of 43 bytes (Base64 encoded); it sounds like you're doing something wrong here.