I've been setting up Snapcast (open-source multi-room audio), and needed to move the server to a different machine. While I was setting up the new system, I told it to only bind to localhost. Somehow this only affects the ipv4 networking stack, as some of my clients started automatically connecting to the new server even before I had finished all my testing.
Turns out that it was advertising some kind of ipv6 link-local address that showed up in autodiscovery. In my case there wasn't any harm, but this type of thing could very easily result in a major security vulnerability.
I'm sure it's totally my fault but that's the point: folks who know how ipv4 works may have huge blind spots for ipv6.
The usual convention for configuring listening interfaces usually involves listing IP addresses or interface names. There's very little room for misconfiguration here, although it's possible. More likely to be a bug in Snapcast (it's almost certainly not an issue in the Linux kernel).
Moreover, this general problem (i.e. configuring listening interfaces) is not/should not be different between IPv4 and IPv6. So introducing IPv6 should not™ incur any additional risk at this level.
But as said, it's hard to get more concrete without knowing exactly what happened in your case.
Things have definitely gotten better over time, though. The massive 90s style corporate networks will probably never transition, but smaller and more modern companies don't have that issue.
Apple mandating that apps are IPv6 compatible and various government legislation forcing companies to make their shitty middleware IPv6-compatible has improved things quite a bit so far. As uptake keeps rising, the need for technologies like STUN and TURN will slowly start decreasing, and as a result more and more people will end up in "untested" situations where not having IPv6 and falling back to legacy paths starts becoming a problem.