Yes, I own a FRITZ!Box myself, so I know how they work.
I don’t think FRITZ!OS requires an EUI-64 IID specifically. It just requires a static IID AFAICT. My experiments with OpenBSD did not reveal any method to manually define a static IID while keeping the automatic update of the IPv6 LAN prefix. So an EUI-64 IID was the only solution I could get to work there. But this is more a limitation of the client OS. I have not researched Linux IPv6 networking to see if the situation might be different there. I don’t use Windows and never had the need to research this on macOS.
Anyway, not everyone uses FRITZ!Box routers, so unless you want to limit your script to their support, a more flexible solution might be a good idea.
Granted, using the local data from the interface configuration saves the need to access an external service such as https://checkipv6.dedyn.io. OTOH figuring out which IPv6 address(es) to use, can be somewhat challenging.
That would be a question for the deSEC folks. I would not have the expectation of this working unless this is documented to work that way.
At the very least it should be documented that you need to use the IP Update API to initially create the records.
Most hosts use NTP to synchronise their clock. So unless that is not the case for your situation I wouldn’t worry about it. In fact the whole issue of high server load at full minutes is caused by all of the clients having synchronised clocks and using cron(8), which tends to start its jobs on full minutes.
Sure. I’d probably increase the window at the start of minute a bit to say :10 - :55, just to give the other clients enough time to do their thing. The 5s at the end are mainly so that our script can finish in time (and to give a bit of tolerance for slight clock offsets).
Also I’d argue that you only need to delay the times the deSEC servers are accessed, not the other stuff the script is doing. So a small function that calculates the next appropriate time and sleeps accordingly, called immediately before any call that accesses the deSEC API would be ideal.
Respecting the Rate Limits is also a very good idea. This could be done by noting the last access time immediately after an API access and taking that into account in the proposed function.