It's most likely fine.
There are a few situations in which you want to communicate with
localhost using HTTPS - such as running a local webserver for web development purposes or some other service that offers a web interface.
The way to do it "properly" is to generate a self-signed certificate, set up your web server to use that certificate, and then manually import that certificate as a trusted certificate. This is a tedious process, and in order to remove this friction, browsers give you the option of pretending like
https://localhost is sending some trusted certificate, even though it's not.
So is this secure? That depends on your threat model. For day-to-day browsing activities, you'll likely be fine. It's difficult for an attacker even in your local network to impersonate
localhost, since it's written directly in your hosts file, which on most setups has higher priority than DNS - which means even with a compromised DNS server, connections to
localhost still would not be redirected to the attacker.
So why is this not the default if it's most likely secure? Because it's not the "expected" behavior of a browser. The expected behavior is that upon connecting to a host using HTTPS, the certificate is validated and the connection is refused if the certificate is invalid. You as end-user have to make a conscious decision to change this behavior and allow this exception.
So when would this be insecure? When would it actually pose a threat? To be honest, I struggle to think of an example that isn't completely contrived. Strange hostname resolution configurations in which
localhost would be resolved via DNS and spoofed to be some host other than
127.0.0.1 would come to mind, but that is a very unlikely scenario, and one in which the user has to go out of their way to configure their system to be vulnerable. However, I don't want to say "it is perfectly fine in every possible setup", since there is always a chance I am missing something.