macvlan is cool in theory. it lets you broadcast a "real" MAC address through your container's veth. this allows it to get a real IP from your router. you can even use VLAN trunking to assign the MAC to a VLAN on your physical NIC.
that said, i only learned about it to discuss it in my course. my dockerized Adguard Home instance uses host-mode networking since that binds the physical ifaces into the container and is just as fast as any other networked process. it's also WAY WAY WAY easier than trying to get pi-hole working in bridge mode, I've found.
(I used to use pi.hole for a long time but AdGuard Home is nicer and updates itself automatically out of the box.)
macvlan can help get you slightly better networking performance by avoiding internal SNAT but it's marginal at best in most cases compared to the work required to maintain macvlan/ipvlan containers. it's also, as you pointed out, not very well documented (because it's not used very often).
This feature along with storage drivers are relics from a time when Docker was poised to own the container orchestration space with Swarm. All of the third-party contributions to Docker Engine basically died once Kubernetes reached critical mass, which was somewhere between 2018 and 2020. Weaveworks was probably the only company with an actively maintained networking driver for Docker Engine, but they are gone now :(