Sort of.
You only get the refresh token if you ask for it explicitly with scope = refresh_token
and your flow meets other documented constraints such as custom protocol on the callback URL. We agree that this "extension" is not compliant with implicit grant type spec. If memory serves, it was created by SF for mobile apps a while ago. While some might still be using it, it's a legacy option as of now.
Implicit grant is no longer recommended. Lightly edited excerpt from oAuth Security Best Current Practice (BCP):
The implicit grant and other response types
causing the authorization server to issue access tokens in the
authorization response are vulnerable to access token leakage and
access token replay
Moreover, no viable mechanism exists to cryptographically bind access
tokens issued in the authorization response to a certain client.
This makes replay detection for such
access tokens at resource servers impossible.
In order to avoid these issues, clients SHOULD NOT use the implicit
grant or other response types issuing access
tokens in the authorization response, unless access token injection
in the authorization response is prevented and the aforementioned
token leakage vectors are mitigated.
Clients SHOULD instead use authorization code grant type or any
other response type that causes the authorization server to issue
access tokens in the token response.
This allows the authorization server to detect replay
attempts by attackers and generally reduces the attack surface since
access tokens are not exposed in URLs. It also allows the
authorization server to sender-constrain the issued tokens (see next
section).
Authorization code grant is known as Web Server flow in SF universe.