What would be the disadvantages/risks of using AF_UNSPEC?

You have to differentiate between client and server applications.

On the client, it is easy: just call getaddrinfo() and try each of the answers in sequence until you get a connection.

On the server, things are a little bit harder:

• There are systems whose IPv4 and v6 stacks are interconnected, there it is enough to just listen on IPv6. Maybe the socket has to be enabled to listen to both.
• Other systems, like Windows XP, have separated stacks where this connection is not possible. There you would have to work with several sockets at once. Let me concentrate on those in the following.

Even on servers, getaddrinfo() can be used. There you use the flag AI_PASSIVE in the hints. Then you get results. On these all you'll have to listen, perhaps enabling the IPV6_V6ONLY flag.

accept() should either be done non-blocking or with select() or poll() (not sure if the latter is possible).

The way things should be:

Applications should be layer-3 agnostic. Connecting to another system should be done by name. The name should be resolved to one or more addresses, and the application should connect to them without looking at the actual protocol being used. That way the networking configuration is the responsibility of the network- and system-admins. If IPv6 is introduced in a network then the application continues to work without even noticing the difference.

Some real-world issues:

Sometimes IPv6 is badly configured, a firewall doesn't know how to deal with IPv6, IPv6 is only used in the local network without a connection to the internet, etc. This should not be a problem, but sometimes you encounter a bad implementation or configuration. To deal with that the IETF is working on a draft called happy-eyeballs. It makes sure that the user doesn't notice such problems. Take a look at that draft. Using the techniques specified in that draft will make sure that your application works good for all users.

One of the risks of using AF_UNSPEC is that you expose the client to larger responses from a malicious DNS server which may be attempting to use CVE-2015-7547 to cause a stack buffer overflow, and cause malicious code to be executed by the client. In fact one proposed workaround for the known defect in getaddrinfo is to prevent use of AF_UNSPEC as detailed here in the bug report. The overflow defect for DNS responses greater than 2K affects glibc from 2.9, and is fixed in 2.23. This affects most currently installed Linux distributions.