it gives public confirmation that the certificate
was indeed issued (and not only the pre-certificate)
To quote RFC6962bis (draft-ietf-trans-rfc6962-bis-28), section 3.2:
"signature" MUST be from the same (root or intermediate) CA
that will ultimately issue the certificate. This signature
indicates the CA's intent to issue the certificate. This
intent is considered binding (i.e., misissuance of the
precertificate is considered equivalent to misissuance of the
Essentially, what that means is that if a precertificate in a CT log is present, then in any sense related to certificate transparency the final certificate was, indeed, issued.
Further operational details (e.g. was the certificate issued then, was the issued certificate then sent to the customer or not, has the customer received the certificate, have they deployed it, etc.) fall out of scope of the certificate transparency framework.
(It is also understood, I believe, that in case the certificate has been actually issued, and not only issued but has been actually obtained by the customer of the certificate authority, then the customer — usually referred to as a "server operator" in CT-related documents — may submit the final certificate theirselves if they have such a policy.)
Hence, there are no advantages left. Yet, the drawback you've mentioned still persists. So, the final score is 0:1 against submitting final certificates.