Good and fair questions. Obviously as a long standing contributor to SILE who uses it in publishing workflows for several publishing companies, I have a bias in one direction here. That being said I have to admit paged.js has made some enormous strides in recent years and I've seen a lot of pretty good things coming out of it. If your developer pool is deeply familiar with JavaScript and CSS it might not be a bad option. I think it would get the job done and I think the output could be good.

I also think SILE can get the job done, and maybe better — but it will take a little more work to get there. You'll spend a bit more time in a terminal and a bit less time looking at pretty page-like-things. But once the work is done having "gotten there" I think you would wind up with more control over the details both large and small.

I think most of paged.js's layout functions are roughly comparable to what you can setup with SILE frames as far as changing between frame layouts (single/double/more colums for example) and flowing one content stream, but one thing I don't think it has facilities for are balanced columns where the it isn't one set of content flowing into both frames but two sets of content that need to be aligned. It has margin boxes and ways of aligning them via a hanging mechanism, but I don't that will work for a parallel Bible translation.

To my knowledge neither has been used in a full scale Bible production job. I've typeset several few Bible translation with SILE, but so far they are review manuscripts for translation teams so the layout requirements are things like double spaced lines with no hyphenation to make proofreading easier, specifically not two column balanced output. I've done multi-column stuff for other projects, but so far haven't had to put footnotes that span columns for example. I'm sure there would be some little kinks to work out along the way, but I'm not concerned it won't be possible.

Here are a couple sample pages of Bible text typeset from USFM. This layout and several others as well are generated in CI every time a commit to the USFM sources lands in the Git repo:

Note little things like the footnotes having both an alpha counter and the verse reference they are found in, running headers that track start and end ranges, etc. Those kind of things were trivially easy to setup just by typesetting the incoming data structures. I'm not an expert on paged.js, but I think to do that sort of thing on the HTML side you'd have to do quite a bit of content preprocessing to generate the content to be styled in place rather than having the style itself be able to generate that because you can hook into any part of the typesetter you like. For example I know they have a counter system based on CSS counters as well as a page numbering system, but I don't think you could make a counter that tracked BCV references in context rather than just an incrementing number. I know you could style the alpha counter, but the BCV format would probably have to be you preprocessing and placing the generated content in the footnote itself before it was styled rather than just being the counter formatter.

Other considerations are whether you need any low level access to things like the shape of words or glyphs themselves, the internals of fonts, etc. Browser tech keeps that stuff at a much greater distance from you the end user than SILE does.

Also, SILE v1.0.0 gets tagged the day we see a full Bible text with the usual ac nutriments go to press without needing any manually fiddling or crazy pipeline hacks on the way (i.e. input your OSIS file and send the PDF to press). At this point I'm pretty sure the holdup is just the state of Bible text projects, not SILE itself. I don't think it will take that much to get SILE there, but there are no projects that are that far along to test it with.