A use-case for this would be in a software similar to JetBackup, according to their support (after I reached out to them) you need to have a .pem file with just the above in it.
Add --post-hook "cat /etc/letsencrypt/live/{domain}/privkey.pem /etc/letsencrypt/live/{domain}/fullchain.pem > /etc/letsencrypt/live/{domain}/MyCert.pem" to whatever command you're using to generate the cert.
While I understand the utility of this, IMHO it is not an idea worth pursuing:
This format is requested to streamline use of a specific, proprietary, software application - not a widely supported open standard.
This format can easily be supported for those who need it by a simple cat command, as all the information is available within each Certificate Archive on disk. Creating this for all users would waste disk space.
This format creates significant security risks, as it mixes the sensitive private secret key with public information. Inexperienced users looking for help could potentially share this file by accident, or social engineering attacks, leading to a security breach.
The paragraph below is requesting a combined public and private key. Considering that the private key effectively contains the public key, one could just use the private key for this purpose.
The example below is requesting a combined private key and certificate chain. I could understand this "package" being provided to a hosting provider for installing the SSL certificate. It's no different than the private key and certificate chain being provided separately except that it incurs the risks identified by @jvanasco.
While @danb35 has exactly the right idea, don't use a post hook. Use a deploy hook (--deploy-hook) instead. A post hook runs after every acquisition attempt. A deploy hook runs after every acquisition success.
I personally would have found this useful as an haproxy user, which is another popular software package that uses the combined PEM format. It's annoying to write a --deploy-hook every time.
For what it's worth, Postfix (a reasonably popular mail server) also prefers the key-and-chain-in-one-file format (as of version 3.4 or higher), since then it's easier to rotate it all at once (as on a running server, if some process updates a key file moments before a chain file, then for that time if the server looks at the files they're out of sync and it's rather confusing). I'm not using certbot myself, but do something similar to the deploy hook described to put the files together and swap out the file all at once for Postfix. (And it can get even weirder, as what I actually do now is have both ECDSA and RSA certs, so they're both in the same file, though Postfix also supports them being in different files.)
I tend to agree that that shouldn't be certbot's default output, but adding samples and documentation on how to use deploy hooks for some popular servers seems like a useful thing to me.