Let's Encrypt has relatively low marginal cost for issuing each certificate, which is one reason that they can be issued free of charge to the subscriber. But it's also true that each issued certificate uses some of the capacity of Let's Encrypt's HSM hardware
—mostly because of OCSP signatures (confirming that certificates are still valid) rather than initial issuance.
The Let's Encrypt community's attitude is, approximately, that people are welcome to as many distinct certificates as they need, within Let's Encrypt's rate limits
but that they should only request certificates that they are really expecting to use for a network service. Let's Encrypt's services are only sustainable at a given level of HSM capacity if most people follow this guideline. 
(If many people routinely issued certificates they didn't use, the rate limits would most likely eventually have to be made more restrictive, which would inconvenience other users.)
Thanks for your willingness to learn about the impacts of different certificate issuance strategies!
A few months ago I suggested that maybe we should invent an HTTP header that communicates that an API service had a non-trivial cost to provide
and then tools that run inside of ephemeral containers, for example, could generate a warning when they saw that header. I'm not sure how well this would work, but it might be worth experimenting with.