This is a very interesting question, and I've given it a lot of thought.

The one sentence answer is "because archive.is blocks DNS requests from Cloudflare's datacenters". That of course leads to the core question: "why?".

This behavior of archive.is is especially intriguing to me because archive.is seems to have an emphasis on being anti-censorship and being resilient, but blocking 1.1.1.1 users appears antithetical to that. cnst's answer is definitely interesting and plausible, but I've come up with my own pet hypothesis that's somewhat similar.

Robust but granular legal censorship compliance

Let's say you operate a website, and must censor illegal content. You might come up with 3 rules:

If content is illegal in country X , that content must not be served to users in country X . If content is illegal in country X , that content must never touch servers in country X . So it must not be stored on those servers, nor be proxied through those servers. If content is legal in country X , we will attempt (within reason) to make that content available to users in country X .

Simple example

Let's have a simple example: you have a piece of content A that is illegal in every country in the world except country X . How can we operate our website within the stated rules? This is fairly simple, put all our servers in X , and if a request for A comes from country X , serve it. If a request for A comes from country Y , give a 404.

Complex example

Now let's have a more complicated example: you have a piece of content A that is illegal in every country in the world except country X . You have a piece of content B that is illegal in every country in the world except country Y . Now there's no longer a simple solution. But here's a complicated solution:

Operate servers in X that have A but not B . If servers in X receive a request for A from X , serve it. If servers in X receive a request for A from outside X , give a 404. And similarly for Y and B . If any servers receive a request for content they don't have they give a 404.

Operate a custom authoritative DNS server for your site. If it receives a DNS request with the EDNS as an IP in X , respond with the IP address of a server in X . If it receives a DNS request with the EDNS as an IP in Y , respond with the IP address of a server in Y . If it receives a DNS request with the EDNS as an IP in some non- X and non- Y country, arbitrarily choose a server IP address to respond with.

Cloudflare enters

If you try to actually implement that solution, you will have a problem: some DNS resolvers (such as 1.1.1.1) don't give you the EDNS, so it's not possible. So archive.is might have done this, then realized that it fails for some DNS resolvers, and so rather than have a semi-broken site, they decided to block users who use those resolvers. There is still the open question though about why block only some EDNS-less resolvers (such as 1.1.1.1) and not other EDNS-less resovers.

Evidence

I've found some evidence in favor of this explanation of archive.is's behavior.

Archive.is runs some special DNS servers on Linode and DigitalOcean. When Linode complained that these DNS servers were used in some way to help distribute controversial content, archive.is defended themselves by saying those servers are just DNS servers, content never touches those servers. This defense uses the same reasoning as rule 2 from above, namely that what matters is whether the content touches the specific servers.

Additionally, in that same conversation, Linode complained that archive.is was doing blocking based on user IP. Archive.is responded that yes, they do censorship based on the country the user is in. This is very similar behavior to what I proposed in the complex solution. As an interesting side note, archive.is viewed this type of censorship as improving legality by ensuring users didn't see banned content, whereas Linode viewed this exact same behavior as hurting legality, by obfuscating behavior, hiding evidence, and making it hard for Linode to investigate.

Archive.is says they are using modern deployment tools and the highly competitive cloud market to prevent wrongful takedowns, which could indicate a complicated setup with servers across many countries and some sort of orchestration system to manage them.

Conclusion

We don't know for certain archive.is's reasoning for their behavior because they haven't fully explained themselves. If their reasoning is legal-based, maybe they fear that explaining their legal setup will expose legal holes in their setup.

The gaps in explanation that archive.is has left provide an opportunity for some interesting technical and philosophical speculation.