The main difference for me is whether or not you have to use server-side storage. This leads to also needing to implement cleaning up the storage, which can be even more complex. You may also need to deal with monitoring storage capacity perhaps only to prevent denial-of-service attacks.

while the signed URI approach is more… robust (if you do it right)?

Actually, using server-side storage is probably more secure(?) despite not using cryptographic algorithms. When using the signed URL pattern, you will eventually need to implement generation numbers where each generation uses a different secret string. This allows you to deal with the secret string being suspected of no longer being secret. Just doing that on a regular interval may be a good idea if you want to be serious about this (but that then requires that you come up with a cryptographically secure random string generator and a secure method for distributing the new strings -- security is hard).

If it’s a free service or something, I’d cache, if it’s a paid service or something, I’d do the hashed/signed URI.

I don't see how one is more professional than the other. If I already had handy a server-side session cache that auto-expires (especially if I was already using it and so was not adding a new denial-of-service point), then I might go with cached GUIDs.

At $work we mix the two. The auto-expire cache holds the details and the only data in the URL is the signature. The signature serves as the key to get the details from the cache. Just signing the URL is much simpler to implement. But hiding the details so that they don't appear in the URL seemed more "professional". (: