The expected result for the Get User script when the user does not exist is the one you mentioned and that is documented:
When using the TRY button with a non-existent user we could indeed be more explicit about the result and instead of showing The profile is: label with no associated data we could instead indicate the user does not exist. However, this would just be an improvement over the user interface for the try script option.
The observed behavior that you mention for the change/reset password situation when correctly using the documented approach to signal non-existing users
callback(null) is the expected one. The reason here, is that the change/reset password endpoint is a public endpoint that could be triggered by anyone. If the endpoint disclosed if the user existed anyone could check if your email was registered as an account at the particular service and this would most likely constitute a privacy violation.
Even though the change/reset password endpoint does not disclose if the user exists, the email will only be sent for existing users and I believe you will have a log entry available that would indicate that someone attempted a password change/reset for a user that does not exist.
With this in mind, your custom database must comply to the documented contract and return in the expected way for a user that does not exist. If you need a custom change/reset password logic that needs to know the user exists beforehand then you would need to make that check yourself, for example, through the Management API.