Presumably you don't trust the CA that signed the certificate on the server at the company you're visiting. As long as you heed the certificate error and don't visits the site, you're fine.
Now suppose you are a contractor who did some work for company A, then went to do some work for company B, and still have some cookies set from A's internal site.
Visit your .internal site -> website uses TLS cert signed by root CA that is preloaded on your device. Succeeds and HSTS flag is set.
Visit other .internal site -> uses TLS cert NOT signed by root CA that is preloaded on your device -> certificate error, and cannot be bypassed due to HSTS.
Yep, ambiguous addressing doesn't save you, same as 10.x IPv4 networks. And one day you'll need to connect or merge or otherwise coexist with disparate uses if it's a common one (like in .internal and 10.x)...
IPv6 solves this as you are strongly recommend to use a random component at the top of the internal reserved space. So the chance of a collision is quite low.
There's usually little reason to use reserved space vs internet addresses, unless you just want to relive the pain of NAT+IPv4. The exception is if you lack PI space and can't copy with potential renumbering.
I've deployed/managed over 25 million production elements in RFC4193 space. These elements ((mostly mesh networking nodes for utilities) ), by definition, should never route to the internet. (According to NERC CIP they shouldn't even route beyond the substation for distribution elements).
Non routability was a design feature.
I've been out of Enterprise IT for 15 years - but if I was going to do an IPv6 deployment today - I would strongly consider NAT6 prefix replacement - it offers 90% of the benefits of native IPv6 addresses, doesn't conflate "security" and "flexibility" (prefix replacement is just a straight 1:1 passthrough - globally routable) - and who want to go update all their router configs and DNS every time they change their upstream. Ugh.