“Making things more snappy”, ok I see where you’re going here 
I know you mentioned Jellyfin before, it’s running on the same server as PMS isn’t it (just checking)?
I’ve not fully tested Jellyfin as of yet. It’s been up and running for a few months, but I only ever intended it to be
- a backup for when/if Plex is having (cloud) server auth issues and I can’t log in properly from my Android TV
- 2nd DVR system to test if it works better the PMS
- just because I can
Jellyfin has felt a bit quicker, sometimes, but without more testing (from me), I just put this down to either (a) transcoding, (b) directplay + codecs being slower at the client end. Only because it’s sat on the same server so it’s not a hardware “thing”.
One thing I don’t know anything about is the simple “how much data gets buffered by the client before it’ll resume playing”. I get the feeling that the client on Plex just wants to wait a little longer for more data; especially with it auto-bandwidth function, since it’ll need a good amount of data to check if things are up to muster 
Also, I know that on Android devices, the client app has an option of ‘enable i/o cache’. There’s not a lot of documentation about this, but might with worth trying to adjust the setting to see if it helps. Though I don’t know if this is available on the Roku
For what I can tell, from a quick a dirty test I did (now 
), the client is defiantly holding on for more data before it starts to resume playing something. Using a 4k film, direct-play, I can see the NIC stats from PMS dashboard rocket up for a few second before the client starts to play. And just as it starts to play, you can see the graph calm down and just intermittently send data. This isn’t scientific as there will be many delays in getting bandwidth data out to a web gui . The same goes for looking at stats on my PC, where I’ve using the Windows Plex Client; I can see a big hit of data come in, and just as the video resumes play, the bandwidth usage drops and it just bursts after that. Again, my assumption is it’s buffering more data than say Jellyfin
Long story short, I’m inclined to say its the clients buffering up before it decides to play/resume Maybe it could be something for Plex to look into, maybe an option in the client to bypass or shrink the amount of data in needs to cache?.. That’s if my hunch is correct
What I will say is, your server is way over-spec’ed, which is no bad thing, and there isn’t a great deal you can do… If both Jellyfin and Plex were slow to respond to skipping/pause/resume, I’d be inclined to say “change how you media is stored”… You mentioned about requesting a feature, you could go the whole hog and record and evidence the speed/rection differences between Jellyfin and Plex? Then you could put a case together for it? Again, they (Plex/Jellyfin) are two wildly different pieces of software under-the-hood, so it’s not a fair apples-to-apples comparison. But I do concur that skipping, in Plex, even on Direct-Play can be slow
). For reference I can run on 8gb, with RAM transcoding, and things are all good. I do run some other services on my server like Jellyfin and Tdarr, so currently I have 16gb of RAM.