Your website is likely hosted on one or two servers in one spot on the Internet. To users physically local to that/those servers yes direct access would be faster, but what about people out of sate? What about those on a completely different continent?
Most of Google's services are hosted in several distinct locations and they use and their DNS setup makes sure that any given user gets sent to the one closest to them.
Even without DNS to help by handing out different IP addresses for the same service depending on the location you are calling from, they have an anycast routing arrangement whereby even when referencing some things by IP address directly you will get a local service of which there are several. For instance if I ping one of their public DNS servers from my home connection (in the UK) I get:
64 bytes from 220.127.116.11: icmp_seq=1 ttl=56 time=30.6 ms
64 bytes from 18.104.22.168: icmp_seq=2 ttl=56 time=29.2 ms
64 bytes from 22.214.171.124: icmp_seq=3 ttl=56 time=28.9 ms
64 bytes from 126.96.36.199: icmp_seq=4 ttl=56 time=38.4 ms
64 bytes from 188.8.131.52: icmp_seq=5 ttl=56 time=36.5 ms
64 bytes from 184.108.40.206: icmp_seq=1 ttl=56 time=12.3 ms
64 bytes from 220.127.116.11: icmp_seq=2 ttl=56 time=12.3 ms
64 bytes from 18.104.22.168: icmp_seq=3 ttl=56 time=12.4 ms
64 bytes from 22.214.171.124: icmp_seq=4 ttl=56 time=12.3 ms
64 bytes from 126.96.36.199: icmp_seq=5 ttl=56 time=12.3 ms
As well as locality of reference, there is the benefit that your most local Google site is likely to be connected to the backbone by a faster pipe than your hosted servers (particularly for users of large ISPs who have more direct peering arrangements with Google). This comes into effect for any static content, or dynamic content where you can tell Google's checker when the content has not changed so the last version can be used, where the user does not need to wait for your server to respond in full to Google
For truly dynamic content this is going to be slower, but for many sites, especially if you have proper cache control on your dynamic content, I would expect this service to produce a measurable speed-up on average (obviously you'd have to test your specific site to see how much difference it truly makes) and it could save you a fair chunk of bandwidth if the site becomes popular.
This is certainly a service I'll keep my eye on with a view to maybe making use of it for certain projects if they ever get off the ground.
The reason for this is that the CDN can keep "hot" TCP connections "open" to your backend origin servers.
Normally, when the user connects to your website, best case, he/she will have to send a SYN, receive a SYN/ACK, send their request in their final ACK (hopefully it fits), and then get their response. That's two round trips.
Then, if the file is "large", the TCP window will start out at some horrible default size, and will only get larger over the course of the connection being used, with successful packets being sent back over great distances and latency.
However, with a CDN, it likely already has a connection open, saving an entire round trip to your server. Meanwhile, if your response is somewhat heavy (multiple kilobytes), the old connection will already have a large window (as bandwidth between the CDN node and your origin server is likely high, even if the last mile to the user isn't), so you will get much higher performance and won't get stuck waiting for ACKs.
In fact, once you start thinking at the TCP level, you realize all sorts of things, like: even if you don't have existing reusable connections, the window will still warm up faster for the CDN (due to their connection being slightly lower latency and likely more stable), yielding greater total bandwidth; and, even more hilariously, even if there is no "last mile effect", having a server halfway between two servers will improve their performance due to these same windowing issues.
Another thing that will help long distance if you use a large enough well managed CDN is the interconnectedness of the CDN's nodes. Google probably has a much better pipe between there point of presence here and the one nearest Qatar (to use your example), so much so that "my server -> them -> then again through their fat pipe -> user in qatar" may well be faster then "me -> user in qatar via other ISP and international peering arrangements".