In my limited testing, Paratext could use a variable font, but without any of the extra weights (either the weights of the static fonts, nor the intermediate styles. So there would be no benefit to using a variable font over a static font family with Paratext unless Paratext is enhanced.
If you use the static fonts, you could use a lighter or heavier weight for the main text, if desired. But then Paratext will fake the Bold weight for use in headings, which is not ideal.
Variable fonts will appear the same as a family of static fonts. In applications such as InDesign, sliders are available to selected weights (and widths) of intermediate styles. See Using Axis-Based Font Families for more information. While that site is about static, axis-based fonts, variable fonts will appear the same way (for the most part).
While InDesign handles variable fonts nicely, PubAssist does not, nor does PTXprint. I don’t know about DBL.
The best use of variable fonts would be in websites, or in the apps from AppBuilders. Then, assuming the website or the framework used for the app supports responsive design a variable font might improve the site/app.
Mobile devices should support variable fonts, especially as responsive design is most helpful on a mobile device. That is, fonts could be slightly adjusted in weight and width depending on the orientation and size of the device screen. But ideally someone with expertise in user experiences and user interfaces should be the one to determine how a variable font would best be used for responsive design.
I don’t know if the AppBuilders would support the use of a variable for responsive design. Even if they do, you would not necessarily need to use a variable font with Paratext. You could use a static font in Paratext and print publishing, and a variable font for web/app use.
WSTech has discussed producing variable fonts, but so far the need for them in our context does not seem that strong, so we have not produced variable fonts.