Why does my browser think that https://1.1.1.1 is secure?

English is ambiguous. You were parsing it like this:

(intranet names) or (IP addresses)

i.e. ban the use of numeric IP addresses entirely. The meaning that matches what you're seeing is:

intranet (names or IP addresses)

i.e. ban certificates for the private IP ranges like 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16, as well as for private names that aren't visible on the public DNS.

Certificates for publicly routable IP addresses are still allowed, just not generally recommended for most people, especially those who don't also own a static IP.

This statement is advice, not a claim that you can't secure a (public) IP address.

Instead of securing IP addresses and intranet names, you should reconfigure servers to use Fully Qualified Domain Names (FQDNs), such as www.coolexample.com

Maybe someone at GoDaddy was misinterpreting the wording, but more likely they wanted to keep their advice simple, and wanted to recommend using public DNS names in certificates.

Most people don't use a stable static IP for their service. Providing DNS services is the one case where it's truly necessary to have a stable well-known IP instead of just a name. For anyone else, putting your current IP in your SSL cert would constrain your future options, because you couldn't let someone else start using that IP. They could impersonate your site.

Cloudflare.com has control of the 1.1.1.1 IP address themselves, and isn't planning to do anything different with it in the foreseeable future, so it makes sense for them to put their IP in their cert. Especially as a DNS provider, it's more likely that HTTPS clients would visit their URL by number than for any other site.

The GoDaddy documentation is mistaken. It is not true that Certification Authorities (CAs) must revoke certificates for all IP addresses… just reserved IP addresses.

^{_{Source: https://cabforum.org/internal-names/}}

The CA for https://1.1.1.1 was DigiCert, which as of the writing of this answer, does allow buying site certificates for public IP addresses.

DigiCert has an article about this called Internal Server Name SSL Certificate Issuance After 2015:

If you are a server admin using internal names, you need to either reconfigure those servers to use a public name, or switch to a certificate issued by an internal CA before the 2015 cutoff date. All internal connections that require a publicly-trusted certificate must be done through names that are public and verifiable (it does not matter if those services are publicly accessible).

^{_{(emphasis mine)}}

Cloudflare simply got a certificate for their IP address 1.1.1.1 from that trusted CA.

Parsing the certificate for https://1.1.1.1 reveals that the certificate makes use of Subject Alternative Names (SANs) to encompass some IP addresses and ordinary domain names:

deltik@node51 [~]$ openssl s_client -showcerts -connect 1.1.1.1:443 < /dev/null 2>&1 | openssl x509 -noout -text | grep -A1 'Subject Alternative Name:'
            X509v3 Subject Alternative Name: 
                DNS:*.cloudflare-dns.com, IP Address:1.1.1.1, IP Address:1.0.0.1, DNS:cloudflare-dns.com, IP Address:2606:4700:4700:0:0:0:0:1111, IP Address:2606:4700:4700:0:0:0:0:1001

This information is also in the Google Chrome Certificate Viewer under the "Details" tab:

This certificate is valid for all of the listed domains (including the wildcard *) and IP addresses.

Looks like the Certificate Subject Alt Name includes the IP address:

Not Critical
DNS Name: *.cloudflare-dns.com
IP Address: 1.1.1.1
IP Address: 1.0.0.1
DNS Name: cloudflare-dns.com
IP Address: 2606:4700:4700::1111
IP Address: 2606:4700:4700::1001

Traditionally I guess you would have only put DNS Names in here, but Cloudflare have put their IP Addresses in as well.

https://1.0.0.1/ is also considered secure by browsers.