I mean, in terms of raw capability, it’s actually one of the better “turn a dumb TV into a smart TV” devices on the market. It has good hardware transcoding support to take the burden off of your server. It also has very little in the way of fluff. It was one of the few boxes that wasn’t packed full of ads by default (though I’m not sure if this is still true).
But yeah, it means you’re locked into Apple’s ecosystem. Which is… Not always the best. Apple is notoriously difficult/annoying if your app gets tied up in approvals, so native apps can sometimes be trapped in limbo for a while. And that’s assuming they even allow the native app.
I guess you could build an HTPC with similar functionality and hardware support, but then you’ll be stuck using a Bluetooth keyboard to navigate things, plus all of the “oh let me wait for my computer to boot up before I can watch anything” pains that go along with it. There are solutions for a lot of the complaints, but a lot of them are fiddly or require lots of extra stuff just to achieve the same basic functionality of “remote has power button that turns on TV and streaming box, and navigates menus as if it’s a native app.”
You shouldn’t even have Jellyfin on a reverse proxy, because it shouldn’t be externally available. There are several known security vulnerabilities (all marked as “closed” due to inactivity on git) that the devs have said will likely never be patched. Because patching them requires breaking away from the Emby fork that the entire project is built on.
It should only be externally available via a private VPN. And that alone excludes a lot of “I want to share my library with friends/family” scenarios, because step 0 will be getting their devices connected to your VPN.
At the very least, set up some form of access control/username+PW directly on your reverse proxy as a secondary security measure. Because if you can reach the JF landing page, you can exploit those vulnerabilities without needing a valid JF login. So you should configure your reverse proxy to act as a gatekeeper, and ensure attackers can’t even reach JF at all without having a valid login to your reverse proxy. But this will break most JF apps (except for browsers) because they likely won’t have any way to give an initial user+pass to the reverse proxy before they hit the JF server.