Most recursive DNS severs on Internet can be categorized in two groups: local DNS servers, offered by Internet providers to their users, and enormous "generic" DNS like Google's 220.127.116.11. When someone makes a DNS request to those servers, they will in turn forward it to DNS servers of web page you are requesting. Content Delivery Networks use DNS to determine, which server should serve your request: if your DNS request arrived from Africa, CDN's DNS server will return IP in Africa. Of course, _users_ don't send DNS requests to CDN's server — recursive DNS servers do. In the past almost everyone used DNS, offered by their Internet provider, — CDN's had to use GeoIP or even static lists of providers to determine origin of that request. When world-wide DNS servers like Google's 18.104.22.168 started to gain popularity, that approach was broken, so EDNS was developed.
Cloudflare is a CDN. They are selling their CDN services for money. At the same time they are encouraging end users to use free DNS server, that does not support EDNS on purpose (they admit so on their website). In effect they are creating a situation, when competing CDNs are at disadvantage and can't determine, what country user comes from. Cloudflare itself does not suffer from that disadvantage, because they control both 22.214.171.124 and DNS, used by their clients' websites.
And Cloudflare is EDNS-compliant. They simply choose not to enable the optional EDNS extension released in 2016 for sending the client subnet for privacy reasons.
Here's what RFC7871 – Client Subnet in DNS Queries says about itself (emphasis mine):
This document defines an EDNS0 [RFC6891] option to convey network information that is relevant to the DNS message. It will carry sufficient network information about the originator for the Authoritative Nameserver to tailor responses. It will also provide for the Authoritative Nameserver to indicate the scope of network addresses for which the tailored answer is intended. This EDNS0
option is intended for those Recursive Resolvers and Authoritative Nameservers that would benefit from the extension and not for general purpose deployment. This is completely optional and can safely be ignored by servers that choose not to implement or enable it.
As far as I know, the standard practice, before this optional EDNS extension was to do GeoDNS based on the resolver's IP. This works just fine, including in the case of Cloudflare, since they've got 150+ POPs with each resolving on their own. That's higher density than most CDNs.