The only reason you can dig through the data now is because the browser gives you tools to do that. The primitive view source or the more advanced dev tools. A web where everything is rendered to canvas would still need to get some data and there is no reason why the browser would not give you the tools to inspect that data.
I think the point is that if the only API that's built into the browser is the canvas, then the browser itself can't know how you're actually structuring your data at all. So the most debugging you can get built in directly is telling you which lines and shapes are currently being rendered. Whereas currently, if you use the DOM, the browser can show you the full rendered tree, show you which elements have events attached, allow you to manipulate elements by putting them in specific states, or just let you delete and modify them in place. The same goes for CSS.
In practice, I suspect if this route were to become more common, then frameworks would provide these sorts of tools directly. The browser still couldn't directly see the component structure of your code, but a framework might provide a browser extension that it itself can hook into, so that you can inspect it as its running. The problem then is that each framework would have to do this separately, because there would be no single base component structure that the browser recognises.
Essentially, you'd go back to developing as it's done for desktop environments - Qt or GTK might provide their own debugging environments, but the operating system itself is generally running at a much lower level, and so can't help you much if you want to know why "foo" is being rendered instead of "bar".
