The point is some protocols require you to actually resolve a domain name. For example, if you set up a vhost or reverse proxy with Apache or nginx, it will use the domain name to figure out what vhost you were trying to access. When you request a page like google.com the browser resolves that to an IP address, but it sends google.com with the request.
So say you have a reverse proxy at 1.2.3.4. You could make two vhosts: site1.1.2.3.4.backname.io and site2.1.2.3.4.backname.io and it would just work from any browser on your network.
You can do this locally using the hosts file before you set up your DNS for real, but a service like this means you don't even have to do that. Useful for quick experiments.
I guess it's the kind of thing if you need it, you'll know. There's no point looking for a reason to use this.
I've done a sorta similar thing to enable HTTPS for local network IPs for IoT: https://news.ycombinator.com/item?id=36593547
This is 100% not possible. The Chromecast always hits Google's DNS to resolve the media server's address. Which means you must host your media under a resolvable domain name, exposed to the internet.
This kind of thing (assuming it can resolve through Google DNS) would short-circuit that requirement. You could feed it a domain name that points back to a local address and not expose your server to the internet.
Of course there are other ways around the problem, but this would be far, far simpler. Honestly it seems like it'd be faster and simpler than setting up a subdomain and reverse proxy, which is what I did.
Or CNAME rrdata. Or MX rrdata. Albeit, there is little point in using it this way, as oppose to just add A record in your own domain anyway...
For people without a domain and a static IP, this may be useful too too publish a page, and possibly obtaining ACME tls cert.
I had to make something similar in the past just for my own use case.