Disclaimer: I am not a Windows administrator
Before even trying to use Let’s Encrypt you should make sure all the names by which users will refer to your Exchange system are fully qualified domain names from the public Internet. So mail.example.net is fine, exchange2013.example.net is fine, autodiscover.example.net also fine, but mail.my.corp or exchange2013 are both no good. Depending on how old your previous certificate is, it may have not have had to obey this rule, but all new certificates from trusted public CAs do.
If you can’t meet this rule, for example if many employees are used to accessing msxch4.internal.corp to get their email and so any new certificate must include that name, you will not be able to obtain a certificate from any trusted public CA. There are a bunch of options for what to do in this scenario, but none are relevant to Let’s Encrypt so I’ll discuss them no further.
Let’s Encrypt also requires that the names not only could exist in the public Internet DNS system but that they actually do exist, and it will usually be easier if they not only exist but correctly reach your servers. If you allow employees to read email at home, or from their own (non-company) mobile devices this is almost certainly already working.
Here’s someone’s description of how to use the tool you mentioned with a newer version of Exchange, that I believe is largely similar. https://github.com/Lone-Coder/letsencrypt-win-simple/wiki/Create-a-SAN-certificate-for-Exchange-2016
Exchange seems to be designed to ideally work using Certificate Signing Requests (CSRs), and Let’s Encrypt definitely can work with CSRs but the description from that wiki page doesn’t use them, it does seem like there’s a definite gap for either Microsoft or a third party to include a step where Exchange just issues the certificates from Let’s Encrypt for itself with one click.