When we say a solution is impractical, we don't mean that it can't work at all; instead, we mean that it has serious deficiencies compared to other ways to solve the same problem. For example, one could use an airplane to go visit your neighbor who lives 100 meters away; we would all agree that there are considerably easier methods, and so using the airplane is "impractical".
The problem that QKD attempts to solve is secure communication; that is, how can Alice send a message to Bob in a way that is "secure". Of course, to try to determine practicality, we would need to consider the other possible solutions and how they compare to the QKD solution. In this case, the obvious alternatives include an entirely symmetric based system (e.g. a Kerberos-like system), and something that uses postquantum cryptography (e.g. Classic McEliece and Sphincs+) .
The line of thoughts which I sketch below is the opinion of most experts and should make it relatively clear.
Here is a list of some major points where the solutions differ:
QKD requires specific types of media to operate
As of right now, QKD can been demonstrated only on short-to-medium length (< 400 km) fiber optic, and free-space communication (point a laser at a target that's within line-of-sight) . If your existing network that uses any other media a significant amount (e.g. microwave or satellite or long distance fiber optic or WiFi), well, you'd have to rework a large part of your network (and good luck trying to get a secure connection from, say, London to Tokyo).
In contrast, the alternative solutions have no such limitation.
What are the security assumptions?
QKD proponents often make the claim "the laws of Quantum Mechanics imply the no-cloning theorem, hence your data is provably secure". While the first part is certainly true, it does not necessarily follow that the data is secure. After all, the laws of Quantum Mechanics do not prove that your QKD device is actually operating as designed, and does not prove that there are no side-channel attacks (that is, attacks where the adversary takes advantage of information beyond what the abstract model gives the attacker) available. Those are security assumptions that a QKD user needs to make (in addition to the relatively safe "QM is a good description of the universe" assumption). Now, QKD vendors are aware of this, and do attempt to provide protections - you still need to assume that there isn't something they missed. See for example this article from The Register.
When we look at the alternative solutions, they are complexity-based (that is, they assume that the computational problem that the attacker must solve is just too hard). At first glance, this might seem like a stronger  assumption; however we can fairly cheaply use overdesigned crypto (e.g. 5xAES256 or AES-ChaCha-Serpent combination, or McEliece with double the matrix size); doing so certainly has a cost; however a far smaller cost than a QKD system. Hence, I would call this point a tie...
How are you planning to authenticate the key exchange?
Plain key exchange can only protect you against passive observers. But real world adversaries tend to refuse to follow our nice idealized attack models. If you want (and you do) protection against active adversaries, who can mount man-in-the-middle attacks, you need authenticated key exchange (see e.g. this paper). How will you authenticate, given that there exists no magical assumption-less quantum signature scheme? You have two options:
(1) With a traditional (computationally secure) signature scheme. But then, you're given up on the reason you were using QKD in the first place, which is to avoid computational assumptions. If you choose (1), then you should definitely consider just running a nice classical authenticated key exchange protocol with computational security, e.g. one based on LWE or coding theoretic assumptions. (*)
(2) With a short pre-shared random key, hardcoded in the device by the manufacturer, then using the Carter-Wegman MAC and QKD to re-generate shared key material along the way. But then, congratulations: you've successfully replaced well-studied computational hardness assumption by a trusted setup assumption: the assumption that the manufacturer is a perfectly trusted third party, who honestly hardcoded uniformly random identical keys in the devices, and of course did not keep any trace of this key, nor did not share it with anyone else. If you are familiar with cryptography, this should ring a bell: avoiding this type of trusted setup assumption is the whole point of cryptography in the first place. In this case, I urge you to consider that "LWE is secure" is a much safer assumption that "my manufacturers is perfectly honest, not greedy, cannot be corrupted, and will not keep the key or share it with anyone".
(*) For completeness, there are two ways in which we should tone down (1) a bit: (a) one might prefer have perfect privacy and computational authentication, since the former is everlasting and the latter is on-the-spot; (b) signatures can be built from symmetric cryptography, and it is theoretically possible that symmetric cryptography exists while public key cryptography (necessary for key exchange) does not. Now, it's a tiny theoretical window, but if this is what you fear and you are ready to pay the cost of QKD to cope with this fear, it is technically a valid reason.
What are you planning to do with this shared key?
QKD just provides a key to both sides; how do we use this key to protect the message (which is, after all, the entire point of this exercise)?
If you plan to use them to encrypt your data with AES, then you're again making a computational assumption, and you lost again this nice perfect privacy QKD was promised to come with. So, here again, you are not paying the price of QKD to get perfect security, but only to gain the ability to rely on post-quantum symmetric assumption (e.g. "AES is secure against quantum computers") instead of public-key assumption. And, remember, one of our alternatives already relied only on this symmetric assumption.
On the other hand, if you use the QKD-generated key stream to directly encrypt the data (with an informationally-secure MAC, one would hope), then we run into the next problem - QKD systems are not that fast. Now, they have been getting faster over time, and given that performance is an engineering problem, not a physics-based limitation, it seems plausible that the speed up will continue over time. However, the speed they go right now is far slower than how fast real networks run - this is a significant performance bottleneck.
Right now, QKD systems are expensive (the cost has been going down; however they're still pricy). In contrast, the alternative solutions can be implemented on standard hardware cheaply.
Bottom line: the alternatives are as good or better on all points.
: A third alternative that I chose not to expand on would be "one-time-pad". I believe that is also impractical; however it may bear comparing to an OTP...
: Quantum entanglement has been demonstrated as a proof-of-concept between ground and a satellite, however there's a long way to go between what they have and a practical usable system.
: "Stronger" means "we have to assume more". In this instance, "stronger" is a bad thing - we want our security assumptions to be a weak as possible.