An ICMP issue does not indicate a TCP/IP problem. IP may have an issue that also affects ICMP - but failure of any external network hop to design to talk ICMP to you is not a problem.
Many network operators won't pass ICMP outside their network. Although many NSPs will.
So, you work(ed) for Zayo, are familiar with the internal device naming nomenclature/topology of their network and can thus definitively identify the routing issue there from some number of unidentified nodes that don't respond to public ICMP?
Oh, that's not right? OK.
While it's entirely possible that there is some issue with Zayo, it's also possible that Cox broadband uses that route incorrectly (whereas Cox cellular doesn't), and so one works while the other fails.
However, what the OP's traceroute actually shows is that it goes via LA, Dallas, Houston and then through DC to Baltimore.
My traceroute traverses Level3, transits their edge in Washington before hitting a Baltimore interface belonging to edgehosting.net. So the OP's traceroute that hits Zayo looks perfectly reasonable, and is not "bouncing around" inside Zoyo at all, as far as anyone can tell from that traceroute.
What is probably happening is that edgehosting either aren't accepting connections from Zoyo, or have a bad route for the return packets.
But nothing can really be inferred from 3 hops that don't respond. The ONLY thing you can tell for certain from external hops that don't belong to you and won't return ICMP information is that (a) they're there and (b) they don't want to talk ICMP to you.
It could be a bad route for Cox on the broadband side of the house, but I suspect an issue with edgewebhosting/Zayo is more likely - given that the packets are getting like, right there to Baltimore and not back...
If it were me, I'd probably ask the folks at motorsportreg.com to contact their webhosting company and tell them that their website is broken for packets transiting Zayo from Cox broadband in SoCal.
www.woodmenlife.org is in Toronto when I try it.