I've been on the fence about whether or not to include the binary in the container (note, I have *no* plans on uploading this to github or the Docker Hub; I'd just post the Dockerfile and docker-compose.yml here for you). The reason I lean towards the binary being in the container is the image should be immutable and self-contained, or else you could get unexpected behavior with future jav-it builds (even though this is unlikely). On the other hand, since the jav-it binary is paid registered software, it's a bit weird to put it in a container, even if it isn't distributed.
Ah, thanks for the kind consideration. In regards to your thoughts, I would mostly agree (I also like containers to be immutable). The only thing I would consider is, this project limits / disables versions that are considered out of date. So as new versions are released, previous versions are retired. This is done mostly to limit service/support tickets open on older versions which are a pain to troubleshoot (especially when simply using the latest version resolve the problem).
That's why I initially suggested having a mount location for the binary, and other upgradable files, since it would make swapping things out super easy. As a side effect, if people wanted to upgrade to the Patreon version and use your recipe, it would make it easy for people to add the latest subtitle definitions files anytime a new pack is released.