My own opinions:

(1) Non-linear cell order (and in particular re-running all dependent cells anytime anything gets changed) is a huge improvement vs. mathematica/matlab/jupyter notebooks. Once you get used to it you will feel crippled when you try to go back. Being non-linear allows the author to optimize for whatever flow best matches the narrative, rather than ordering things based on arbitrary implementation-specific requirements of the programming environment. It is also possible to e.g. put simplified or brute-force implementations inline in the prose, and then move tricky optimized versions to technical appendices at the end of the document.

Being non-linear also allows for showing some placeholder output right away and letting expensive-to-compute output (or slow-to-fetch data) execute after initial notebook load and progressively replace the placeholders. This lets readers get started reading the prose right away without needing to wait for slow operations.

(2a) Being able to pin the source of a cell to be shown / hidden at the author’s discretion makes for an improved reader experience in the typical case (assuming a conscientious author). Nobody wants to read e.g. big blobs of redundant LaTeX source in addition to their mathematical formula output. Needing to sometimes click to show code that an author left hidden in the initial view is easy after just a tiny bit of experience as a reader. As an author I tend to mostly leave prose markup pinned closed and code cells pinned open (unless they contain too much distracting or overly technical detail) when publishing notebooks.

(1 & 2a) These two features both change incentives for notebook authors: since code can be hidden in the default view authors are not afraid to use a better implementation which includes distracting technical details; in other notebook environments I have noticed authors intentionally use worse-performing but simpler implementations, and technical details often get moved to some external library, hiding the code much more deeply than just putting it in a cell with hidden source / moving the cell to the bottom of the document.

(2b) I also prefer output below code, but the reason for the order here is so that showing/hiding the source won’t make the output jump up and down the page excessively; with a bit of experience the other order is not really an obstacle in practice.

(3) It’s Javascript (with a few minor additions as shown in TFA), but you can use whatever javascript tagged template you want, including html, markdown, or anything else you can dream up. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

(4) It is fairly easy, but it’s a fair complaint that it takes some trust / involves some risk to build work on top of a closed-source platform, especially for folks with strong free software ideology; even if it is possible to mirror code outside observablehq.com, it is at least mildly inconveient, and necessarily loses access to some great platform features. I personally have a lot of faith in the Observable team’s commitment to not breaking documents published on their platform or letting them disappear. But when business is involved, there’s no absolute guarantee.