You have a few misunderstandings.
when you connect to an HTTPS website, the communication is encrypted via asymmetric encryption
This is false. The communication is encrypted using symmetric encryption (typically AES or a Salsa20 derivative), which is orders of magnitude faster than asymmetric encryption and supports bidirectional secure communication without needing both sides to have a private key. The symmetric encryption key is derived from randomly-generated data for each new connection, and is ephemeral (forgotten after the connection ends).
Exchanging the symmetric encryption key - the process of ensuring that both the client and the server have the same symmetric key but an eavesdropper does not - can be done using asymmetric encryption. This is how RSA-based key exchange works, and only requires that one party (in practice, the server) have a public/private key pair. However, most modern TLS connections don't use asymmetric encryption (per se) at all, opting instead for an ephemeral key exchange algorithm, usually elliptic curve Diffie-Hellman (abbreviated ECDHE). DH-based key exchanges do involve public and private parameters, but nothing is encrypted or decrypted with them, and to make the key exchange secure the server's public parameter is signed (not encrypted; the mathematical operation is the same in RSA but not in some other signature algorithms and the purpose, concept, and security are totally different) using its private key.
Once the TLS "handshake" (which includes the key exchange) is completed and actual message traffic (encrypted using a symmetric cipher) starts flowing, generally private and public keys are not used again for the rest of the connection.
My understanding is also that each computer (let's just assume Windows) has at least one private key stored in its hard disk.
In practice this is probably true, but not in a way that is relevant to HTTPS (or any other use of TLS). Private keys are used for a lot of things, and Windows does in fact generate them in many cases (typically at least one per user and probably others), but for TLS in particular usually only the server has a private key, which should always be generated specifically for that purpose, and the corresponding public key is distributed as part of a certificate. TLS clients can have their own private keys and certificates - such "client certificates" are used for mutually-authenticated TLS, sometimes abbreviated MTLS - and your browser supports this, but most people will never use that functionality.
If my private key gets stolen, what can the ill-intentioned person do?
If an attacker steals a server's TLS private key (which is the only private key involved in most TLS communication), then at a minimum the attacker can impersonate the server. Doing so requires the victim's device to route traffic to or past the attacker, but there are multiple ways to do this: DNS spoofing, ARP spoofing, owning (or taking over) a router or gateway or proxy or VPN server that the victim is routing through, etc. Demonstrating possession of the server's private key is the means by which the client authenticates the server - that is, by which your browser confirms that, when you navigate to https://security.stackexchange.com/, you're actually connecting to the real security.stackexchange.com server - and confirms that it is performing the key exchange with that server (and not some network attacker, typically called a "man/monkey in the middle" or MitM in situations like this). The attacker (having spoofed the legitimate server and/or having MitM position) could then read everything your browser sent to it, and fake its own responses, or even forward traffic to and from the legitimate server while invisibly decrypting and spying on the contents, with the option to modify them at any time in either direction.
Additionally, if your server was using RSA key exchange or any other key exchange that is not forward secret, and the attacker had recorded previous HTTPS sessions connecting to your server (including the handshake), then the attacker would be able to use the stolen private key to re-derive the exchanged symmetric key and thus decrypt the recorded message traffic in both directions. Similarly, if the attacker had an MitM position on an ongoing connection to your server (and had recorded the handshake of that connection), the attacker would be able to begin decrypting and optionally modifying the network traffic in both directions. However, the reason that ephemeral key exchanges are so commonly used these days is that they provide forward secrecy, such that stealing the private key after the key exchange concludes does nothing to the security of that connection. The attacker needs to actively tamper with the key exchange itself when forward secrecy is used; there's no way to re-derive the symmetric encryption key after the fact.
For the sake of completion, if you are using MTLS and an attacker steals the private key for your client certificate, then that attacker will (most likely, assuming they also got the certificate - which is usually public - and there's no other authentication) be able to impersonate you to servers that expect that certificate. Think of it as being like stealing your password, except instead of you entering a password, your browser uses the private key to sign some data at the end of the TLS handshake and thereby proves your identity to the server.
