Depends on your definition of secure.
For something to be secure, it should have the following three components of C.I.A (at minimum):
Does this link meet C.I.A requirements?
Having a download link like this: https://example.com/de2e1ecd-d5ee-42a7-8980-969961a4f397 meets the definition of confidential in and of itself because it is computationally infeasible to find this file on purpose without prior knowledge of where it is. Brute forcing the site and trying every possible combination would take millennia.
The example uses SSL (TLS) so it is protected in-transit as well.
This does not meet the integrity requirement. We have no way of knowing if this document was altered by a MiTM attack, was changed by a bad actor at the server, etc... The file just is sitting on the server.
This file link does meet the availability requirement. Navigate to the URL, get the data. Doesn't get more available than that.
Where does the security break down?
The security of this link breaks down when you start to transmit the link to people to make it available.
Transmitting the link in plain text via email breaks any security that the GUID-named file ever gave you because unauthorized people can get access to the plain text URL.
In order to maintain the security, you would need to use a method of communication that used both encryption and authentication. Encryption protects the URL in-transit, and authentication ensures the person reading it is the correct person, and allows them to ensure the person who sent it really was you. (This adds even more complexity because computers cannot really guarantee the person reading the message is the intended recipient. An unattended, unlocked iPhone, the recipient held at gunpoint and forced to open the message, etc... could all be possibilities on how the message could be read by unauthorized personnel.)
This link never had integrity, so it can't be broken.
This link's availability is still maintained here.
How can you improve the security of the link?
- Add a password for access to the system. A good on. 16+ characters, which are randomly generated from a password generator. This opens up yet another issue of password security, but for now, just use random passwords at a minimum length of 16. This adds a second factor, and secures the link against eves droppers. Of course, you can easily break this as well if you send the password in the same email as the link. The password must at minimum be sent out-of-band. (Email link, call and tell them the password). NextCloud and ownCloud offer this obfuscated link + password option, for example.
- Use GPG / PGP to send the information to the recipient. This allows you to encrypt the message and sign it prior to sending it to the recipient. The recipient also has to have their password to decrypt the message. In this scenario, the information is properly and safely transmitted to a recipient, which maintains the integrity of the GUID link. Alternatively, you can use Signal or WhatsApp, which make this same process transparent and have widely accepted security standards and protocols.
- Use public key cryptography to sign the document. Signing the document at the download location allows remote users to verify the document is in its exact, intended state and has not been tampered with since the original author authored it.
How much is too much?
You have to decide what your threat model is. What problems could you have if this file "gets loose?" If it's pricing for a customer, which may be different on a per-customer basis, and you don't want the customer to be able to guess another account to shop you, just the link is probably sufficient. If you're transferring confidential secrets that you don't want the company IT guy to find if he's bored, you're going to have to step it up a notch. If you're transmitting government secrets... well ... you get the point. Figure out what you are worried about first, then define the security parameters that need to be met within that context.