In the actual internet world, IPv6 is not safer than IPv4. Read this:
https://www.internetsociety.org/deploy360/ipv6/security/faq/
That article in fact details several ways in which IPv6 is harder for malicious actors to attack. Although not explicitly stated, it's common sense that something which is harder to attack is going to be safer unless it has some other massive weakness, which in this case it does not.
It's also somewhat misleading, for instance it talks about "increased complexity of ipv6" but in many ways ipv6 is simplified, for instance the packet header is simpler, routing is simpler because routers no longer need to recalculate the checksum each time they forward a packet, nor do they need to bother with fragmentation and reassembly. Many features which were later added to IPV4 such as PMTUD are standard parts of IPv6. This makes IPv6 less complex not more, since you still have to deal with these things on an IPv4 network but with IPv4 you also have to deal with the fallback case where these newer features are not always supported.
People only perceive IPv6 to be more complex because they are unfamiliar with it.
There is also the complexity of implementation to consider. While IPv6 can be deployed as designed, IPv4 requires various extensions, as well as various hacks designed to conserve limited address space. Complexity is the enemy of security.
Perhaps they are comparing original IPv4 to IPv6, rather than the extended IPv4 that's in general use. For instance packet fragmentation was always considered a problem, so path mtu discovery was created as an alternative. However while all IPv6 implementations are required by spec to support PMTUD, IPv4 may or may not - so in practice both fragmentation/reassembly and PMTUD need to be supported whereas IPv6 may only use PMTUD.
Original IPv4 only supported address classes, CIDR was also added later and there are old/embedded implementations which don't support it at all.
In terms of security specifically however, there are several advantages to IPv6:
With IPv4, the most common technique used to discover vulnerable hosts is simply to scan address ranges. Doing so you will find every host and every service. Various automated worms use this method to spread, it's extremely effective and once one machine is infected your whole network typically comes crashing down in minutes if not seconds. With IPv6 scanning ranges is simply not practical. There are other techniques possible such as DNS enumeration, but these are more time consuming, more difficult and less thorough. On the other hand you as the network owner can always know what addresses are live by viewing the address tables on your routers and switches, so you can pass the list of active addresses to your scanning or pentest provider and still retain full coverage of your devices.
This is touched on in section 2.2 of your linked article.
TL;DR: the classic scan and compromise attack becomes much harder, you as a defender have a lot more breathing room to patch, and a lot more margin for error if you put an insecure box on an open connection.
Elimination of complexity such as NAT. With routable addresses you have simple firewall rules - external address block A is allowed to reach server B on port C.
With NAT, you have external address block A is allowed to reach external address B on port C but it's actually translated to internal address D and port E. You have to retain and correlate multiple addresses for each service, mappings of ports on the same address going to different hosts etc.
You have other mess like nat reflection rules etc, and have to worry about things such as nat slipstream attacks. Complexity is the enemy of security.
Due to NAT a single address can represent multiple users/hosts. This causes all manner of security problems.
We were performing a red team assessment against a company a couple of years ago, we found their external email service and began trying to guess credentials. They quickly identified this activity, and blocked the host we were guessing from.
So we bought a prepaid simcard from the same operator they use for their corporate mobiles, and continued password guessing from there. Because the IP address pools for the 3G users were shared, if they blocked these addresses they would also be blocking their actual employees. They didn't block the addresses, and after a while we got lucky on guessing some creds (there is always at least one user with a poor password).
I encountered another NAT problem while investigating a security breach. A company had a critical server compromised, and the attack had come from one of their branch offices. They traced the attack back to a router located at the branch office. This router was performing NAT for the ~4000 machines behind it, and was not logging every state (doing so would have caused a severe performance reduction of the router requiring a more powerful one to be purchased, as well as somewhere to store the logs). As such, we had absolutely no idea which of the 4000 potential systems was the source of the attack.
IPv4 was never designed to use NAT, since it was designed for use on a relatively small military network with tens of sites and maybe a few thousand hosts in total. You can transport lots of people around by having them hang on to the roof and bumpers of your car and cram them in like a clown car, or you can use a bus.
There are LOTS of open proxies on the internet, there are even big lists of them published and people use them for anonymous browsing of internet sites... But how many of these are connected to an internal network and would let you attack internal hosts using the proxy? If you're maliciously inclined you can find out, issue requests to the proxy for addresses within the common RFC1918 address space and see if you get any hits. The address space is small, so you should be able to sweep it all and see if there are any internal devices reachable via the proxy.
With IPv6, the open proxy less likely to be found in the first place, if it is found it still won't be practical to scan the /64 that the proxy sits inside let alone try to brute force any other address ranges that it might have access to.
Modern operating systems are designed to use IPv6, and consider it their primary protocol. They will only fall back to legacy protocols like IPv4, IPX/SPX, NetBeui etc if IPv6 is not available. If you connect a modern host to an old network, it will typically sit probing for an IPv6 router and/or DHCPv6 server constantly. A malicious attacker on the local network (esp open public wifi) can answer these requests, and become the primary DNS server and primary network route - thus hijacking traffic. While this is technically possible against protocols that are actively in use too, it's harder to pull off (you have to fight against the real dhcp/dhcpv6 server, and risk causing a very noticeable denial of service). On networks where IPv6 has not been configured, its extremely unlikely to be noticed. This is briefly touched upon as points 1.2 and 3 in your linked article, but he doesn't mention that an explicit lack of IPv6 infrastructure on a legacy network containing modern hosts makes this attack easier to accomplish.
You can search for the tool "mitm6" which can accomplish some of these attacks simply.
The greater address space of IPv6 allows you to better design your addressing plan, with better segmentation between functions.
One of the things stated in your linked article is: "IPsec employs Extension Headers, which typically result in packet drops when employed on the public Internet (see [RFC7872])."
This refers to IPv4, where the AH/ESP protocols are not recognised by some older and/or shoddier implementations, resulting in the packets being dropped. These protocols didn't exist when IPv4 was designed, so they were never considered.
IPv6 implementations are all capable of passing AH/ESP packets because it's part of the base spec. They will only be blocked or dropped if you explicitly configure a firewall to do so.
In section 3.4 he touches on SEcure Neighbour Discovery (SEND) and suggests there is no widespread support for it. While it's true that it's not widely supported by default, support can be installed on all modern operating systems if you require it. IPv4 has no equivalent to SEND at all.
Section 3.5 he details a DoS attack against NDP. The same attack can be performed against IPv4.
Section 4.4 he details an attack against packet fragmentation, similar attacks are possible against IPv4, but are more likely to succeed because support for fragmentation is not optional for IPv4.
Microsoft, Facebook, Cisco, the US government etc are all deploying IPv6 for security reasons among other things. These organisations employ a great many experts in the fields of networking and security, they know what they're doing.
There are also many non security related benefits to IPv6, which i've not touched upon as the subject was security.