we cannot expect our clients to be able to use encrypted emails therefor regular unencrypted emails have to be used
Moreover, the recipient server might not speak STARTTLS, and the connection may fall back to plaintext over the wire. (I expect your mail server to at least try to use STARTTLS always, bonus points for SMTP STS support)
the attached file is way easier to manipulate or replace in an unencrypted email than it is on the webserver
It depends on the type of risks you face. A file on the webserver could easily be manipulated by you, or if your webserver was somehow compromised.
A week after sending it you might change the invoice doubling the amount. If the invoice was in an attachment you would not need to do anything.
we reduce the size of the email and therefore the size of the mailboxes of our clients
I find this is an important point for mails with large attachments and accounts nearly their quota. On the other hand, the attachment is simpler for archiving, as that allows to simply keep the emails (maybe automatically filtered into a folder), whereas the link requires someone to download it (autodownloading scripts are probably magic for most of your clients accountants). And some Cloud email solutions offer infinite mailbox storage, so while for some clients it's important, it will be a non-issue for others.
obviously the link could also be manipulated however we think this would be easier to notice
The average client would probably not notice that the link goes now to a completely different domain.
the GUID-filename provides some degree of security against simply guessing a valid filename
I expect you mean a random GUID (type 4). Yes, an url with enough entropy should be 'good enough' if handled properly. However, the secrecy of the file is as good as the security of the url.
It is probably easier to "leak" the url than the file. For example, an email filtering or antivirus solution might share the url as "bad". The user itself could scan the url in VirusTotal (that will then happily download the "public" file).
Some users will nevertheless also share the attachments, though.
It would be much preferable that the files are encrypted. As they are invoices, they could be password-protected pdf, so the clients wouldn't even need to use a different program to open them. Although if there's an expectation that the clients will want to store the invoice without password protection, I would use a password protected zip file (using the modern AES encryption, of course, not the unsafe classic one).
Even if you include the password in the email along the url (which will still make some people claim is not secure, as someone that stole/copied that email would have both the url and the password at their disposal), that would be safer [than not having a password at all], as an inadvertently leak of the url would lead to a file that is still password protected.
Moreover, the storing the invoices encrypted also protect you somewhat against potential mistakes from your part (e.g. your random GUIDs turn out not to be that random, and someone downloads all the files). Particularly, when you use a different random password on each email and don't store it, so even you couldn't reveal its contents (OTOH if in the same system you were storing a db column with "the" pdf password for each customer, an attacker might steal everything).
In general, in my opinion adding a password to the file seems a measure adding interesting benefits while requiring low skills from the receiver. But, this is a feature you are rejecting:
(an additional password is considered to be too complicated by some of our clients)
and this reveals your actual problem. You are trying a one size fits all approach, but some of your clients consider attachments preferable than links (while others will consider the opposite), some demand a "more secure" approach and others are unable to open a password-protected file.
I think you should make it configurable.
Use a reasonable default, with password protected files (either as an attachment or as links, allowing them to change that), but let the user "dumb it down" by actually disabling the file encryption, and also provide a PGP key to which you would encrypt their email (and/or linked file).
That later option, while being the most secure one, will be a niche one with only a tiny fraction of your clients actually using it, even with a fairly technical user base. So the actual value of that option is probably going to be the availability of it more than the users of it: that you can offer your clients to use a much more secure way for sending them the invoice, if so they wish, even though they are most likely to decline.