First, if you know what you’re doing (sounds like you do) and know what you changed then if you see any problems happen down the road you will know how to undo them and will know why/what caused it so you are probably ok.
I have no problem with people tinkering and trying stuff and will be the first to admit I do this type of thing myself to check for possible improvements.
However, my mini “rant” was that I worry about other people reading this since it’s a public forum and think that Plex got something wrong and that they need to change the priority of the transcode process also.  THEY DON’T.  I probably should have worded that better but it’s early morning and I just got my first cup of java. (apologies) 
First on the electrical thing I mentioned.  If you have a whatsup meter or similar you can connect it inline between your computer and the socket and watch how much more power some computers use when the CPU kicks in to what’s called turbo mode.   It goes from an energy saving mode to a power hungry monster (exaggerating). This is computer dependent of course but something to check if you have a meter to do it.  Kind of cool to know how much juice your system is using under different loads.
That aside.  The Plex transcoder is used for a lot of different processes that take place in Plex.  From image extraction, to optimization, to syncing to bif generation to meta-data collection to real-time encodes.  There is no question about this as you can see the commands issued in the logs files.  So with that said making a change the always makes the transcoder run at a higher priority may or may not be a good thing to do depending on what process called it.  For example if I just added new media and plex is adding it to my library do I want the meta-data data gathering and the BIF file generation competing with the two real-time encodes that need to happen or do i want Plex to manage this BIG generation as a background task not competing with the real-time encodes?
That’s just one of many different types of things you could change the outcome of.  On a more powerful computer you might not notice one way or another but on a machine just hovering above 1.0 transcode speed or could be the difference between successful and not successful real-time encoding.
Plex does internally manage the priority of different uses of the transcoder.  It does give priority to real-time transcodes over what it considers background transcodes such as Optimizations and SYNCing for example.  Plex intentionally doesn’t want them running at the same level as the “foreground” real-time transcodes.
Plex has thought of these things and does take them into consideration.  You can see this yourself by starting a file optimization and watching it’s CPU use.  Then start watching a file that requires transcoding on another computer/device while watching the CPU use.  You’ll see the transcode used for the optimize take a lower priority and the new real-time transcode dominate the CPU.  It’s done this way on purpose.
What I was referring to about real-time CPU use.  If you look at settings/server/transcoder setting you will see entries for “Segmented transcoder timeout”, “Transcoder default duration” & “Transcoder default throttle buffer”.  These essentially control how often the transcoder runs and how far ahead of the client it needs to be.  So regardless of the priority of the transcoder when it “fills” the buffer it will throttle the encode anyway.
This is why you’ll see a high CPU use followed by it doing nothing, then high, then low again.  It runs only when it needs to.
Now with all this said which is just the tip of the iceberg so to speak of how it works, what are you trying to accomplish by changing the priority manually?  Are you experiencing a problem of some kind?  Is Plex not keeping up with transcoding properly?  What’s the issue you are trying to solve?
Carlo
PS Yes a couple of options are no longer available to set.  Plex doesn’t need to know that OPTIMIZE and SYNC for example should be run in the background vs a real-time encode.  It does that by default now.  It gives them the resources needed unless those resources are needed for a real-time job. Hence why changing priorities can lead to unexpected behaviors.