This sort of scheme is common so that you do not have to share the encryption key with the provider. You derive two keys from your plaintext password: one used for authentication and one used for encrypting / decrypting the blob. This way, Lastpass can authenticate you without having to see the key to decrypt your data.
Not sure the specifics of how lastpass implements this but this is a really common approach for end-to-end encrypted apps.
I wouldn't say it's so you don't have to share the encryption key with your provider (you achieve that with a separate encryption key), but rather so you can use a single memorable secret for both login to the provider and local encryption.
As in, the idea is that it is used to save you from having two secrets which might be more or less easy/hard to remember.
It's a UX improvement (which might be a security imorovement on average too).
The client-side hashing is actually the part that keeps your master password a secret, from everyone including LastPass yourself. This makes sure that LastPass cannot decrypt your passwords despite them being stored there. The server-side part on the other hand is severely misimplemented and not much good to anyone. This is one of the issues I’ve written about here: https://palant.info/2018/07/09/is-your-lastpass-data-really-...
From what I understand: you still need the master password locally to decrypt the individual passwords. A hash won't provide that. All you're doing here is logging into LastPass.
Not sure the specifics of how lastpass implements this but this is a really common approach for end-to-end encrypted apps.