tl;dr: Not really. But that's OK, because if your branches are protected properly you don't have to worry about what people do in their own repos.
Explanation: the reason the answer is not an exact "yes" or "no" is because you could set up commit hooks in your own repo to prevent certain actions if you want to. You could also recommend others do the same in their repo. But it's their repo and you can't force them to. Similar to how you can't force someone to arrange their keyboard and mouse a certain way on their desk, though you can make suggestions. You absolutely can lock down the branches in the central remote repo, and it sounds like you've done that, and that should be sufficient.
Regarding your specific concern:
...may it happen that by mistake someone may locally merge its feature branch on the master and then being blocked while pushing it to GitLab and by that messing up the commits?
No commits will be messed up on the remote repo due to this. If you have configured master to only allow Merge Requests, then it doesn't matter what anyone does with their own copy of master, since they can't push it. Besides, it's good practice to test merges before completing MRs, so if someone wants to checkout master locally, merge in their feature branch, and then run unit and system tests against it before completing the MR, they should be allowed to do this. (This is especially true if developers aren't rebasing their own branches onto the latest master before completing the MR.)
To summarize: this is not something you need to worry about. Let developers do whatever they want with their own repos. Just make sure you inspect the commits during a code review of each Merge Request. That way you'll spot if someone is messing up the graph by including their own merge commits in their MR. But you should probably be looking at the commits before completing a MR anyway.
Tip: I recommend that most developers should never (or very rarely) checkout shared branches such as master and develop. Oftentimes the initial reaction to this is people think I'm insane (until they hear my explanation). The reason I say this is that if you have a local copy of that branch, it's pretty much always out of date. When you first learn Git you may learn to git checkout master and then git pull to get it up to date. Then you create your branch from there with git checkout -b my-new-branch (or git switch -c my-new-branch) and you're off and running. But eventually you will forget to pull the latest master and start creating branches from older versions of master. So what do you do instead? Anytime you want to use the master branch, simply use origin/master! Assuming you git fetch regularly (which you should), origin/master will always be up to date, so you never even need to bother wasting time checking out master and pulling it. Just skip those steps entirely. As I mentioned previously in this answer, if you want to checkout master to merge in your feature branch and test the merge before completing a Merge Request, you can still do that, but consider naming the branch something other than master, perhaps something like, test/my-feature-branch instead. Or if you do check out master to test your merge, just delete it as soon as you're done with it. Or better yet, just rebase your feature branch onto the latest origin/master and test that instead.
If you like that tip, here's another: "Developers should never (or very rarely) pull!" I'll leave that for another discussion...
Note: notice that in both of my "never checkout shared branches" and "never pull" rules of thumb, I purposefully refer to "developers". Managers, Product Owners, and to some extent DevOps folks, probably should be checking out shared branches, and perhaps also pulling since it makes more sense for their use case. The key here is that these groups of people are typically using a repo in read-only mode, or in the case of DevOps engineers, they are oftentimes merging shared branches into each other.
