How to prevent users from changing Computer name

There's no way to granularly control that setting in System Preferences > Sharing. Apple doesn't have any mechanism to only lock down certain items in the panel's sidebar. I wish there was, but it doesn't exist.
Either you need to lock down the entire panel, or you would need to set up a process that would run locally on each Mac to check its local computer name against what it should actually be, either from a local plist or file for example, or by using the JSS API to grab the record's name from the JSS. if they end up being different, the process would reset the name back to what it should be.
It wouldn't be anything instantaneous, but it would work to "correct" the name. I imagine eventually your users would get bored with trying to change the name.

Thanks @mm2270 ... do you have the guide to do it?

I lock out (make it grey) the Sharing Preference pane using a Config Profile. My users have no business poking around in there.

Additionally, I use a policy as Ongoing to "Reset Computer Names" (Under the Maintenance Payload) that is triggered on Startup in the event one of my users is bright enough to figure out scutil.
I've been running this above policy since my jss was version 6.62.

-my 2 cents
:)

Like @pvader we also lock out our Sharing preference pane from users. The reasoning for us is that there are precious few items in the Sharing pref pane that we deem safe for users to mess around with. We don't want them changing the name (from the GUI, still possible from the command line), we don't want them disabling Remote Management or Apple's ScreenSharing, we don't want them turning on File Sharing or Web Sharing, we don't want them turning on VNC (its super insecure due to the static password that we can't control or enforce any policy on)
This really doesn't leave much for them that we (or more accurately our SecOps folks) would feel comfortable allowing them to mess with. As such, its just not worth leaving it open for them.
Note that many of the above items, not just the computer name, are possible to manipulate from the command line. Since all our users are admins, it does present a challenge, but for us, its really about making it difficult and sending a clear message we don't want them messing with this stuff. Essentially, if you manage to scale the barb-wired fence with the Keep Out sign to get into the forbidden zone and get caught, you can't claim you weren't given a clear message that the area was off limits in the first place.

@mreaso As for an exact process, we aren't doing anything like what I described before (see above), so I don't know if I can give you an exact process. Just a framework.
What I'd look at is deploying a local LaunchDaemon that runs maybe once a minute. When it runs it can run a local hidden script that would check the local machine name and compare it against a file that contains the name of the computer as you named it (this can be created with a policy that runs on each machine once, or deployed at imaging time or computer setup, after its been named for example) If it finds a difference between them, it would rename the computer back to what's contained in the local file.

It could also check for the computer name via the API as I mentioned, although I don't know if I would rely on that. For one, you would have to either embed API credentials into the script, or use methods to obscure the creds using encrypted strings. It would also only be effective if the script ran while the Mac is on the network or internet and can connect toy your JSS. In this latter scenario using the API, you run the risk of the computer submitting inventory back to your JSS and updating the record with the newly renamed computer name before the process has had a chance to correct the name back, which could foul things up.

These setups are only just examples. If you do some searches here on JN, I'm sure you'll find a few threads that discuss methods people are using to name machines back to the way they need to be. Its not the first time its been asked here.