There are definitely benefits to specifying the charm revision in your bundle such as reproducible results as @szeestraten mentions, however, Canonical’s best practice for new cloud builds is to not specify a version in the bundle when deploying a new cloud in order to get the latest and greatest versions and bug-fixes on day one.
Do note, however, if you re-use the same bundle without specified charm release numbers to make config change updates, re-application of the bundle with new options settings can unintentionally upgrade your charms to latest revisions if they are not version-pinned in your bundle.
To avoid this, I recommend starting your deployment without a pinned version, and then using “juju export-bundle > bundle-to-update.yaml; vi bundle-to-update.yaml; juju deploy ./bundle-to-update.yaml” to make updates to your juju model w/out losing any live changes or charm upgrades you may have made, and to avoid unintended charm upgrades during re-application of the bundle.
If you do pin your revisions in your bundle, be sure to keep up to date on the patches applied to the stable release branches to ensure you adopt any relevant bug fixes that are released ad-hoc between major charm releases.
Also of note, with the regular charm release cycle (19.04, 19.10, 20.04, 20.10), if you’re testing a bundle in august w/out pinned versions and you go to re-deploy in October after the release of 19.10, your deployment will benefit from the new charm revisions which will have many feature enhancements and bug fixes, but may require reading release notes for other required changes to your bundle to ensure compatibility of your configuration with the next major charm release.