What's really important about it is that it's using an edge cache ("edge caches" are a type of CDN, though there's also "push CDNs", which domain fronting doesn't do anything for).
A lot of companies, including Google and Amazon, run a bunch of reverse HTTP proxies (called "edge caches") all over the world as a way to reduce latency, since if the cache already contains a file, it doesn't have to go all the way to the backend server to get it. They don't just spread the backend servers themselves all over the world because they're more expensive, they're optimized for particular applications, and because database consistency gets harder and harder the more you spread out the replicas.
Since the edge caches are application-agnostic, the same one can also be reused for multiple apps. Your browser, then, can talk to the same edge cache all the time even when it's actually interacting with several different services. This is where domain fronting comes in.
As a quirk in the application protocol, your browser ends up sending out the domain name it wants to interact with three times:
1. During domain resolution, where it uses the DNS protocol to convert the relatively human-readable names into IP addresses. In a domain fronting session, this step has to use the "front domain".
2. During TLS negotiation, where it requests a signed certificate corresponding to a domain. In a domain fronting session, this step also has to use the "front domain".
3. During the HTTP request. HTTP doesn't just rely on the DNS one, because the same IP might have multiple domains, and it doesn't just rely on TLS, because HTTP is supposed to be able to work over plaintext. In most edge cache implementations, the HTTP domain is the only one that's actually used to decide which backend server to talk to, so a domain fronting implementation like Signal will use the "target domain" here, and since this is part of the HTTP session, MITM-based blocking systems can't see it.