In this example showing two different approaches to serialization of the same exact GPS data, the author finds a way to save 57 bytes of data on each trip. 57 bytes may not sound like a lot. But depending on how busy your API is, 57 bytes can make several differences. For example, at significant scale, not only could it mean less work for the servers that are powering your API's endpoint, it could also mean less network load (perhaps easier on the load-balancers), less data to cache, and, in some situations, could even mean less total cost if you're paying for bandwidth. Again 57 bytes on a few transactions isn't going to break anyone's bank. But at scale, over time, it could be significant.
Yet another use-case where 57 bytes per transaction can make a difference is when when the data is heading to or from a mobile client. We've all been there when our phones have had weak connectivity over a spotty cellular network, desperately trying to eeek-out every byte through what seems like a pin-hole of a connection. If your API is a chatty one, as might be the case where a mobile device might be sending and receiving GPS coordinates on a regular basis, one of those additional 57 bytes could be the one that breaks the camel's back, causing an API transaction not to complete simply because the network decided to drop out in the middle of some transaction's round-trip.
Finally, this example does a good job of demonstrating one of JSON's great strengths: readability. But, as the author demonstrates, you don't want to take the JSON-trimming too seriously, especially if it's going to compromise readability.