I'm unable to find any discussions about the use of "SSL Generator" tools (e.g. https://punchsalad.com/ssl-certificate-generator/) on the forums.
This concept seems to undermine the security of TLS, since certificates generated this way have passed through an unknown intermediary.
Is anyone else concerned?
Yes.
It would indeed undermine the security of TLS if (and only if) the private key wasn't kept, well, private. But a webbased client isn't insecure per se.
Some webbased ACME clients would generate the private key in the clients browser using clientside scripting. If the private key stays there and is never transmitted to somewhere remote, then there isn't a security risk, strictly speaking.
However, one would need to check the sites code to be sure of that every 3 months....
Another method is using a CSR. That's perfectly safe of course 
Certificate key disclosure isn't the only problem with these.
If the website proxies the entire ACME process using its own server-side account key, then all of a sudden you have an extremely valuable ACME account that can issue additional certificates for an unauthorized CSR without having to do any proof of control (for however long the ACME server allows authorization reuse).
The old ZeroSSL was good on this point because the browser was talking directly to ACME via CORS XHR, but plenty of other web-based clients fall foul of the above problem.
I think a good signal to pay attention to is that Let's Encrypt has, since the start of 2019 late 2018, refused to list web-based clients on ACME Client Implementations - Let's Encrypt.
Even as the author of a website ACME client that was created to replace ZeroSSL and SSLforfree (and does use its own ACME account key when generating all certificates), I would be remiss in not referencing the following excellent analysis:
My client ONLY accepts CSRs as I do not believe it realistic for anyone to (continually) review locally-operating code to ensure that private keys are not stolen. Honestly though, how many people (@_az and @Osiris here aside) actually review any client's code before using it? At least with restriction to a CSR, the client has zero exposure to your private keys. Trust lines...
The explicit risks of using someone else's ACME account key:
A reasonable concern. 
The CA signature enables verification of the authenticity of a certificate to prevent tampering or spoofing.
If you don't trust an ACME client with handling your certificate, you can always:
fullchain.pem.I don't see how passing the certificate through an unknown intermediary generates a risk? You suggest using crt.sh, which is another 3rd party in the mix.. Proving certificates are out there in the public domain. Getting it from the webbased ACME client or from a certificate log isn't really a difference to me.
I fully agree, my friend. But for someone who may not currently understand what you and I have written though, the concern is very reasonable. Deferring trust to a tool known and trusted by the CA (crt.sh) and providing a resource from the CA itself (X3) provides a secondary or redundant means of confirming the behavior of the client (by comparing the two full chains). Which do you trust more: punchsalad or crt.sh? 
I'm not sure what you mean by that? How is crt.sh "trusted" by "the CA"? Which CA? What kind of trust? Crt.sh is a certificate log aggregator. You and I could do the same thing (if we had too much money and didn't know what to do with it.)
What do you mean by this? I'm failing to see the connection with X3 (I assume you mean the issuing intermediate cert used)?
Neither. I trust the validation of the certificates signature with a local copy of the intermediate certificate in combination with the local private key corresponding to the public key in the cert. And a check if the correct extensions are set (such as must_staple).
You've been in this too long, my friend.
You have to put yourself into the shoes of someone who would ask the original question. Someone who does not have your level of experience or expertise.
I would hope crt.sh is trusted by the CA (Let's Encrypt) considering what community we're a part of and the fact that crt.sh is directly mentioned in our Help template. It's not so much a matter of who could do what, but who's known for doing it.
As you well know, what someone needs to acquire in order to enable https for his/her website is an unbroken certificate chain with his/her website being a leaf. It is somewhat obvious how to acquire the leaf certificate from crt.sh. What remains is being aware that the intermediate certificate is probably needed, knowing a (trusted) way to acquire it, and knowing what to do with it (build fullchain.pem).
What you wrote makes perfect sense to me and yet is absolute gibberish to the layman. Someone without an understanding of what those words mean may still not have a clue how to validate the signature. What such a person may have a clue about is diff. If I receive the exact same text from an ACME client that I have also downloaded from a source trusted by the CA (crt.sh), I can have reasonable assurance that the client isn't trying to lead me astray. I can apply the same process and logic with the intermediate certificate provided by the client and the one downloaded directly from the website of the CA. Thus, a layman's verification of fullchain.pem (and an alternative means of acquiring fullchain.pem should I forget to copy the certificates off of the final webpage of the certificate process of a website ACME client and am unable to return to that page without submitting a new order).
I'm thinking you're confusing "endorsement" with "trust". Crt.sh publishes every cert which is included in the certificate logs they monitor, even incorrect certs issued by a CA. As long as it chains to a root allowed by the log. This is of course good, so we can monitor CA's for erronous behavior. But you shouldn't automatically trust the certs in crt.sh. I've no idea why.
Why is that? Crt.sh will show any cert issued by the CA and succesfully submitted to a monitored log. I still don't know what makes crt.sh so trustworthy.
That's different IMO. The website of the CA is usually secured with TLS, providing authentication of the host you're downloading it from. So that's a direct and authenticated connection to the CA. Crt.sh is absolutely no such a thing.
I think "trust" here has more than just one meaning.
I trust that the content to be correct/accurate doesn't mean that I trust the source as I would trust a CA.
Perhaps I've used the wrong terminology - I am that layman that you speak of. By using a hosted SSL Generator tool, isn't the private key that is not public also passing through this third-party?
At the time of posting this original question, I was not aware that these tools might be client-side only (entirely written in JavaScript)... that does slightly change the scenario. Assuming someone is regularly reviewing the client-side code to ensure it's not stashing a copy of the keys remotely.
One could argue that these tools aren't any different than certbot or acme.sh or any other acme client. Any acme client could be sending a copy of your keys to a remote server, that's true. From my inexperienced viewpoint, generating these encryption credentials has always been a process that usually involves two parties - me and Let's Encrypt (who I trust because they're the source of the credentials)... sometimes the process also involves my DNS provider (who I also must trust because they are already trusted to provide DNS).
The entire system of encrypting traffic relies on trust, and a service hosted by a third-party that runs between Let's Encrypt and the receiver of the encryption credentials exposes those credentials unnecessarily to that third-party. Knowing that this exists erodes my trust of the internet's encryption scheme.
Perhaps I create a password generator service, then any passwords generated by the service I add to my rainbow tables which I also sell for bitcoin. Then perhaps I create an SSL generator service, and I stash a copy of the encryption credentials which I also sell for bitcoin. Then perhaps I create services for syntax highlighting / linting server-side code via the browser, but I stash a copy of the code that is provided which I also sell for bitcoin. I take these services, multiply them with different branding and hostnames and work to promote them to the top of search engines. Now an attacker with a specific target can come to me with an IP address, and I may be able to provide them with passwords, source code, and the private keys of his target.
I agree that I'm a layman, not nearly as experienced as either of you are with regards to TLS and encryption... and from this layman's point of view, a third-party hosted acme client seems like a really bad idea. It'd be nice if those services also publicly exposed the hostnames for the certificates they generated so I can be sure not to transmit any sensitive data to them 
. To be clear though... I've never been overly concerned about anything I've transmitted across the internet needing encryption. These SSL generators just seem like a bad idea to me.
IMHO: The potential for abuse far outweighs the reduction in effort.
Anyone that can install a provided cert should also be capable of operating an ACME client to get one.
I'm thinking of starting a "free bank depositing service" - give me your money and I will carry it to the bank for you - LOL
But I wouldn't even count on that kind of trust. As I said earlier, crt.sh is just a cert transparancy log aggregator. It doesn't have more or less certs than a CT. Which gets their certs mostly from the CA anyway. The only thing you can count on when pulling a cert from a CT log, is that it chains to a trusted (for that CT log) root cert. By the way, AFAIK Let's Encrypt runs a CT log for their staging certs 
So much for trusted certs!
Not necessarily. It's perfectly possible to get a cert without anyone reading the private key by using a CSR. Read about what CSRs are and you'll know how this works.
That ACME account can also revoke the already issued certificates.
Osiris has it exactly right regarding the certificate signing requests (CSRs), which is what I mentioned above that the ACME website client that I authored myself uses to get you a certificate. The whole idea behind PKI is that you don't and shouldn't trust any third-party entity (including an ACME client) with the integrity of your certificates. From reading your response, I'm doing my best to conservatively gauge your experience, so I apologize if some of what I'm about to say might be known already to you.
When generating a CSR, it is customary to generate a new public-private key pair on the server where the certificate is intended to be used. This secures the private key by minimizing operations performed on it and thus minimizes its exposure. The public key is included in the CSR along with several pieces of information related to the entity to which the public key belongs. Once the readable content of the CSR is prepared, it is signed (encrypted) using the private key with that signature being appended to the bottom. Now, anyone possessing the public key (which is available in the CSR itself) can use it to decrypt the signature and compare the result to the content to ensure that the content has not been tampered with. The CSR contains no private information and is safe to pass to the world, including a potentially-wayward ACME client.
When the Let's Encrypt uses a CSR to generate a certificate, it results in updating various transparency logs (which Osiris and I have mentioned or alluded-to many times). Some services (e.g. crt.sh) provide a means to search those logs AND download PEM versions of the certificates. Let's Encrypt provides both your certificate and its intermediate certificate that was used to sign your certificate. That intermediate certificate can also be downloaded directly from the Let's Encrypt website. Thus, as long as Let's Encrypt has been provided adequate proof that the controller of the domain(s) identified on the CSR wishes to have a certificate issued using that CSR, Let's Encrypt will issue that certificate. From that point, the website ACME client can just be closed and the other means mentioned can be your (more humanly-trusted) sources to acquire what you need.
Q: What if the website ACME client deviously generates a new CSR for me (including generating a new public-private key pair)?
A: Unfortunately, Let's Encrypt has no way of filtering this and thus a certificate will be issued. However, if you attempt to install this dubious certificate for usage on your website(s), your authentic private key will (most likely with great probability) not match the dubious private key used to generate the dubious CSR. This will mean that the dubious certificate and authentic private key will be incompatible and you will know.
Fun fact: the RSA public exponent (e) used for almost every website on the internet is the same (65537). It is the modulus (n) that varies based on both the public exponent (e) and the private exponent (d).
Osiris is very good at playing devil's advocate and presenting additional/conflicting information to check what I've presented. It's one of the things I've learned to respect about him. So don't take our banter as anything other than healthy discussion. We're all comrades here.
We are? 
I understand CSRs... but that sounds very silly to me - having the technical ability to generate and copy a CSR but then needing to bring it to an SSL Generator to fetch the certificate. In my experience, the commands to run a given acme client are far simpler and more intuitive than any openssl command I've ever seen.
So are those the two options available for a completely client-side (JavaScript) acme client? Using a CSR or via a DNS provider's API? It was unclear how something like that would validate the domain. /side-rant
Here's the (extremely laborious) gold standard:
Every ACME client submits a CSR to the CA. Some generate it for you (and thus must be trusted with your private key).