I would say it's not an issue.
Try googling it a bit. It seems to be a good practice to not do it.

In my opinion : we must FORCE white space inside a password ;)

Now I see the light of this -- yes, spaces should be allowed (although maybe a warning should be displayed that the password contains spaces)... I just cases where if one cuts and pastes a password, a space gets added and people don't always realize that.

Yes : showing an information about surrounded whitespace is a good idea :) +1

HOWEVER, a big problem is that by default the system sends the password on a password reset request as open text in email... That's not so good.

I know this can be disabled by setting this in config.php (which prevents sending password at time of account creation, and removes the "Forgot your password?" question on the login page:

'display_user_password_in_email' => false

I notice with this set to false, that when I create a user account, the system message on the create user dialog still indicates that the password will be sent to the user via email, even though it won't be: I recommend that message should instead indicate the password WILL NOT be sent if config setting is 'false'.

While obviously a user with permissions to create/edit users can reset user passwords, there are scenarios whereby an organization policy states that end users should be the only ones who know their passwords.

With 'display_user_password_in_email' => false, the user has no way to reset their password. This could be resolved with a single user password reset link instead of sending passwords in emails. Some of this logic likely already exists, since there is the config setting for use_one_time_passwords (but it is designed for external systems that create accounts in LS -- maybe this can be extended to the core system...

Or maybe there are other great ways to prevent passwords being sent by email, but still allow users to request password resets (like a password reset link -- instead of sending the password in the email).

And on top of all that, if 2FA using Google Authenticator was a feature that could be enabled on all user accounts, this would give end-users the option to apply an additional layer of protection on their user accounts.

The real fix is :

• Sending a temporary link with one time password to the email
• When user open this link : redirect to a page to set his password.

:)

Yes, this would be a good approach to start with.
Right now though, I don't believe this can be natively done in LS right? I can set:
'use_one_time_passwords' => true

But I still get the standard login email...

Any thoughts what would it take to integrate the link with onetime password into LS?

One day work (maybe more), and only in 4.X