I forgot to add the most annoying/unfixable problem that would arise if Xfinity were to start making my leases highly dynamic: VPN config for the half dozen or so client devices. I always connect to my VPN when I leave my house, and it would be extremely annoying to have to constantly change my WireGuard config on my personal devices. In that case, the only practical solution would be to use my VPS as the VPN-I could then configure such traffic to be forwarded via the site-to-site VPN to my server/router at home if I desired. Seeing how I've been an Xfinity customer for almost 8 years and the stability of my leases haven't changed, I'd be pretty surprised if they greatly changed how leases were assigned.
The other part I forgot was the case where your services need to be globally routable because you don't control the entire routing stack (e.g., an SMTPS server) thus a ULA won't work. Unfortunately I think your only solution is to rely on a VPS or something with truly static IPs. You can then route traffic from it to your server/router via WireGuard. As someone who runs his own e-mail server at home, I basically need a VPS simply for the fact that e-mail can be blocked if the IP addresses associated with your server are considered "residential". At that point since I already need a VPS, I just carve out IPs from my VPS's block and assign them to my servers at home. In fact my VPS is nothing more than a router where traffic gets routed via the site-to-site VPN; thus services like smtpd(8), dovecot(1), and nsd(1) use IPs from the IPv4 /29 and IPv6 /48 that are routed to my VPS. As a result, the config for those services and any associated DNS records don't need to be touched even during the rare time my IP leases are changed and even though such services are actually running on servers at my house. Of course it's more inefficient for traffic to first be routed to my VPS in LA then to my house in Denver via a VPN tunnel and back, but the additional latency is more than tolerable and is worth the money saved from having to not pay for a static block of "non-residential" IPs. Obviously if the services I were running were more "critical", I wouldn't skimp like this.
