I know this means that I won't be able to add an AAAA record to the domain,
This is wrong. The incompetance of the domain registry has no bearing on the record types you can use (unless they force you to use their servers as the authoritative namesevers in which case I would suggest running far away).
but what does this mean for reachability/compatibility/visibility from other IPv6-capable DNS servers?
If the zone for the tld isn't available over ipv6 then ipv6-only resolvers will not be able to resolve the domain.
If the zone for the tld is available over ipv6 but they won't let you provide IPv6 glue records then things get more complex. If your nameserver is under the domain in question then an IPv6 glue record is needed to support IPv6 only resolvers. If your nameserver is under another domain then glue records are not needed for your domain (though obviously they are needed for some domain).
Dual stack resolvers should be fine in any case. The chances are most DNS resolvers will be IPv4 capable (either dual stack or v4 only) for the forseeable future.
I understand that DNSSEC is somehow important for authenticating DNS resolving, but have no idea if/how its implementation (or lack thereof) affects me as an application developer when it comes to security.
Dnssec is supposed to provide a mechanism to verify that the records you receive are genunine. However
- The vast majority of systems don't enforce it at this time.
- verifying the records are legitimate isn't really much help for A and AAAA records. An attacker who can mess with DNS can also very likely mess with IP routing.
DNSSEC with DANE is a potential future replacement or supplement to the current CA system. The current CA system is highly flawed from a security perspective because it effectively leaves you only as secure as the worst CA.
You don't say what sort of applications you are developing. If it's client app that talk to a server you own then you should secure your connections using tls with a private CA.
For webapps the public CA system (crappy as it is) is really the only option. You might want to consider HKP which tries to reduce the risk from mis-issued certs. Having working DNSSEC/DANE would provide better security but only for the handful of clients that actually support it..
If you are designing your own protocol which allows use of arbitary servers you might want to consider including an equivilent to hkp.