hamsub: You haven't said who your ISP is. If like evolutionofwrestling it is also BT, then that would be a potential clue where the problem lies. If I were talking to someone at my ISPs support, I would ask them if they could browse the site in question from their machine rather than just asking them if they were blocking anything, and it it failed I'd want to know where in their traceroute it failed.
Also, it may not be that a particular ISP is actually blocking anything, but routeing tables do sometimes innocently get wrong entries in them (and often won't get fixed till someone reports it), and this would only affect those end-users whose ISPs were using those routes. I'm on Zen and currently see no such problems (any downtime I've seen at T35 has also been witnessed via multiple foreign proxies so was almost certainly genuine T35 downtime and generally doesn't last too long (probably a reboot or an attack)).
Without a traceroute, it's difficult for anyone to say how far the connection attempt gets before it dies. It may not even be getting as far as the border routers of your own ISP, which would place the fault definitely within the hands of your ISP (or at least, the resolution to the fault).
Sadly, even with a traceroute, it's not guaranteed that you'll pin-point where it goes wrong. My own traceroute has 10 hops. First is local, then 6 at my ISP, then 3 in the US including the destination IP, but only T35 support would be able to advise on whether the 8th and 9th are their responsibility or the responsibility of a service or backhaul provider.
I'd even suggest that your own ISP has a responsibility to investigate here. Given that the T35 sites clearly work (for other users, and for yourself via a proxy), your ISP (if they themselves cannot access the site directly) should pass a fault upstream to their transit provider, who can in turn pass it up to theirs till they find out where it's failing. Sadly getting support departments to help in this manner is a bit hit and miss.