The idea is to limit the power of the credential, so that when it's stolen, the negative impact is mitigated.
In the paper, they compare macaroons to plain cookies. When you steal a cookie these days, you can take control of an entire account -- maybe even change the password, etc.
In this situation, with the simple HMAC / guid / hash, once somebody "steals" the URL, then it can be leaked to everybody, forever. It can't be fixed without "breaking" the app.
The macaroon technique can also solve the expiration issue. In my post, I described how you would add a caveat for the filename. You can also add a caveat based on time. So then stealing the Macaroon would only authorize the attacker for a limited team -- even a single request (this is talked about in the paper).
A legitimate user can be minted new macaroons constantly based on his login. But the attacker can be locked out based on the expiration. So the attacker's problem is elevated from stealing a single cookie/macaroon to stealing either the login or ALL macaroons, which is generally harder. With Macaroons, you don't have credentials of full power constantly traveling back and forth over the network.
That is my understanding anyway... actually implementing it will probably reveal some more insights.
The only problem I see with such approach is lack of expiration policy (other than re-loading the file under a different name every now and again).