https://www.jointjs.com/blog/jointjs-vs-gojs
but without any direct references to GoJS.
The emphasis on the foreign object tag in this most recent article ties in with their latest release, in which one of the selling points is the ability to embed HTML elements inside SVG elements. What they fail to mention is that an even more flexible approach, not supported by JointJS, is to render HTML elements as the vertices and embed SVG inside the HTML.
The article does make some valid points but on the whole comes over as slightly disingenuous. "A painful amount of code" has to be written to support a `:hover` class with canvas may be a true statement, but done properly it only has to be written once, and most likely not by the customer of a diagramming library vendor but by the vendor themselves. It's true also that a basic canvas setup "doesn’t preserve clarity when resized" but I've read a few things written by the author of GoJS in which a clear strategy is presented to mitigate the issue. There are many other small points like these peppered throughout.
Regarding accessibility, I have also wondered about this since seeing Google switch over to canvas for docs. It seemed extremely unlikely that they would have done so and abandoned accessibility, and a cursory search shows that they're currently using a 'side DOM', ie. maintaining a DOM that contains only accessibility stuff. This is again not something that a user of a library should expect to have to maintain themselves. You'd expect to add a vertex to some library and for that library to handle the side DOM, using accessibility information that you've provided, and that you would have needed to provide had you used a library that renders to SVG instead.