The eth0 case seems to be the “normal” one. Is my guess is correct that eth0_1 is a secondary IP defined on the same hardware/macaddress as eth0? I set up a secondary IP on my primary internet interface, but I’m on wireless and that device name is wlp82s0, so we’re already enough different — my udev rules are probably not like yours at all (what OS are you on, btw?) — that comparisons may get iffy. Unfortunately, that doesn’t give me an ansible_wlp82s0_1. It’s only listed as a "ipv4_secondaries" sub-dict under ansible_wlp82s0. Hmm.
There was another thread the other day, get-the-name-of-an-interface-for-a-given-ip, where the same problem was dealt with albeit for a different purpose. The solution there was to loop over the ansible_<interfaces> data to add the benign defaults for otherwise missing data for the secondary addresses. The whole point was to avoid blowing up on missing data.
It looks like you’ve got 3 options: (1) use a technique similar to that in the linked thread above so you’ve got sufficiently fleshed out dicts for your secondary IPs, (2) skip the src_interfaces that don’t have macaddress defined (simplest by far, but has implications wrt why you’re renaming these interfaces), and finally (3) reconsider what’s driving the desire to rename these interfaces and attack that as the problem to solve rather than – to be blunt – tossing away the udev work done by your distro for questionable gain. Granted, why you’re trying to do this has not been discussed, it’s your business not mine, etc. But after the tiny bit of reading I’ve done over the last 48 hours on udev rules and device naming, I’d need to hear an extremely compelling argument before I’d go down that road. And maybe you have one. I just wanted to include #3 because, speaking for myself, sometimes I fixate on implementing a solution to a problem that shouldn’t be solved, but rather eliminated further upstream.
I would still like to see what your ansible_facts['eth0_1'] looks like (assuming that’s the one blowing up on you).