Security is often not as black and white as “insecure” or “secure”. Whether you should use Windows Hello in the current version - just like whether you should use it before the update - depends on your threat model. If an attacker with high forensic experience running code on your unlocked system after you lock your vault is within your threat model, then you should not use Windows Hello unlock. In many cases, this attacker model may be too strong, and the aforementioned scenario occurring may be not worth considering. (If your system is locked, they’d need to unlock it. If your system is shut down, the keys are gone and your vault is no longer accessible without the master-password).
Such an attacker with full access to your system could also already steal all session cookies from your browser, since the encryption measures browsers do take can be circumvented, as shown by the previously linked GitHub project on chrome’s ABE, without ever going to your vault.
So, whether or not the current Windows Hello implementation meets your needs, and whether you should use it is up to you.
(Note: The above does not affect MacOS touch-id or Linux system authentication unlock. Apple Keychain is separated per signed app context, and on Linux, the process holding the keys uses special kernel features that prevent debugger / memory access).