In my comment, '"cracking" referred to finding a password that matches the hash. That's common nomenclature. The found password doesn't have to be the original password but it's rather likely at the string lengths involved, especially since Kaspersky used a dictionary to back the attack.
Also, you wouldn't use a hashing function where a large number of inputs of a usual password length turn into the same hash. That would just make all passwords weaker. The point of hashing a password is to store something that (ideally) uniquely matches the correct password but can't be used to easily derive the password.
The factor of 1000 I gave was a very rough ballpark number. I couldn't find any good comparison between the actual throughput of MD5 and bcrypt or Argon2. And yes, a single round of SHA256 would be cracked quickly; it's much less work-intensive than Argon2 and even has dedicated hardware acceleration in modern CPUs. Argon2 with a high work factor is vastly more resistant than MD5 and SHA256.
Also, salting doesn't protect against brute force and enhanced dictionary attacks. The salt is stored with the password so the attacker knows it. It only protects against rainbow tables. Pepper protects against offline cracking.
That is one way an attacker can gain access to the browser's memory. It's not the only way.
Besides, administrative access does not necessarily mean that the attacker has complex attack code for every possible scenario included with whatever they're running. The more work they have to do to access your data, the less likely it is that they're doing that specific work.
Leaving stuff lying around in the open because an attacker potentially could have a specific countermeasure to more strict safety measures is equivalent to giving up. At that point you can just forego security at all because whatever you have might potentially have an exploit.