Intuitively this seems reasonable, but, as a sense check I want to put the other side: Not necessarily with the goal that you change your mind, but that you didn't end up just doing what was intuitive without weighing the options.
The public CAs are run pretty well, and they have people actually overseeing them to verify that remains so, without you lifting a finger (well, unless you'd like to help oversee them at least). In contrast a local CA is very likely to be poorly run, because it's not really anybody's actual job to do it properly, you can't justify the expense [If you're Google, then, sure, you can justify the expense but also you are not asking about this on HN] to train them, they can't afford the time and effort to do their best work.
The public CAs are almost certainly not going to lose their root private key, if bad guys do steal the root key for a CA, it'll make news and also you almost certainly aren't the target, in contrast the root key for your private CA probably lives on somebody's laptop (which can be left on a train) or a server somewhere.
There's good tooling for the public CAs. Your software might already come ready to use ACME, and if it doesn't you will find instructions pretty easily. In contrast although there are technology stacks for this stuff without the public CA context, they're not as widespread, particularly in Free Software, and you may find if you need certs for five systems that means five separate tools. Or you do it manually which sucks.
Everything already trusts the public CAs. It's not difficult to tell Mac OS, Windows or even a Linux distro to trust some root CA, but it's an extra step to be done and if you forget it may be difficult to figure out why things don't work. For some services that's enough, but if you also want BYO devices to work that's a nightmare, likewise for guest devices.
Names will almost certainly leak anyway. If your goal is to hide the fact secret-project.example.com exists, I strongly recommend instead changing it to some-codename.example.com so that you needn't care much if the name leaks.
None of the above makes mkcert a bad idea - mkcert is for development. But you should weigh this when deciding whether internal-git-server.mycorp.example should just use Let's Encrypt certificates rather than spinning up an internal only CA.
The public CAs are run pretty well, and they have people actually overseeing them to verify that remains so, without you lifting a finger (well, unless you'd like to help oversee them at least). In contrast a local CA is very likely to be poorly run, because it's not really anybody's actual job to do it properly, you can't justify the expense [If you're Google, then, sure, you can justify the expense but also you are not asking about this on HN] to train them, they can't afford the time and effort to do their best work.
The public CAs are almost certainly not going to lose their root private key, if bad guys do steal the root key for a CA, it'll make news and also you almost certainly aren't the target, in contrast the root key for your private CA probably lives on somebody's laptop (which can be left on a train) or a server somewhere.
There's good tooling for the public CAs. Your software might already come ready to use ACME, and if it doesn't you will find instructions pretty easily. In contrast although there are technology stacks for this stuff without the public CA context, they're not as widespread, particularly in Free Software, and you may find if you need certs for five systems that means five separate tools. Or you do it manually which sucks.
Everything already trusts the public CAs. It's not difficult to tell Mac OS, Windows or even a Linux distro to trust some root CA, but it's an extra step to be done and if you forget it may be difficult to figure out why things don't work. For some services that's enough, but if you also want BYO devices to work that's a nightmare, likewise for guest devices.
Names will almost certainly leak anyway. If your goal is to hide the fact secret-project.example.com exists, I strongly recommend instead changing it to some-codename.example.com so that you needn't care much if the name leaks.
None of the above makes mkcert a bad idea - mkcert is for development. But you should weigh this when deciding whether internal-git-server.mycorp.example should just use Let's Encrypt certificates rather than spinning up an internal only CA.