I fully agree, there isn't a good reason. The issue is that flaw is a systemic one in Windows.
Modern operating systems should be operating under zero trust. The fact that Windows still operates on Intranet Era logic, where if a file is reachable, it’s probably safe, is exactly why these exploits keep happening.
The problem comes down to a Windows API called ShellExecute. When an application like Notepad passes a link to this API, it is effectively saying to the OS, The user wants to open this, figure out how to run it.
Windows looks at it and essentially says, Oh, it's an .exe on a network share? The user must want to run that software, launch it, rather than, This is executable code from a network location I don't control, download it and make the user double-click it themselves.
The main reason it does this is for legacy enterprise convenience. Decades ago Microsoft designed Windows so that companies could put internal tools on a shared drive and employees could run them instantly. They prioritised seamlessness over security by assuming the network perimeter was the security boundary, and everything on it was there because they wanted it to be.
Obviously that assumption is dangerous. Like you said, no remote executable should ever be treated as trusted by default, regardless of whether it came from the Store, an SMB share, or a web link. The action of clicking a link should never map directly to execution of code. It should map to retrieval of data. Microsoft basically turned a convenience feature into a permanent vulnerability.
Will it though? What exactly is it doing differently? Because to my knowledge the only thing that matters is using more water. Having more water inherently cooks it longer. It's done when all the water is absorbed/evaporated. That's why you can use basic rice cookers with nothing but an on button for both white and brown, just get the water ratio right.