You still have the canvas, and it's perfectly easy to draw on that and handle events in JavaScript. There are a number of applications that work that way.
That said I disagree with the idea that using the DOM is bad - I suspect it's cumbersome to you mainly because you're not used to it. The number one benefit of the DOM is that user-facing controls are largely consistent. If I want the user to type text into a text box, I can just use a browser-defined element, and the user will be able to interact with that exactly as they expect. I don't need to reimplement the whole text input and display process, because it already exists in the platform. The same goes for all sorts of controls and interactions, from zooming to select boxes.
Moreover, assuming this DOM is built up in a way where the semantics are embedded in the elements themselves, then it can also be used in different ways. One user might use their browser to render the DOM into something that can see on their screen, while another might use their browser to read the element contents aloud. One person might use their mouse to interact with the system while another might use their keyboard. Accessibility is built into every application built using the DOM - it may not be ideally presented in some situations, and it's still possible to get things wrong, but by default a blind user will at least have a chance of using the system. In contrast, a canvas-based application will need to reimplement accessibility from the ground up (usually in the form of a secondary hidden DOM tree).
That said I disagree with the idea that using the DOM is bad - I suspect it's cumbersome to you mainly because you're not used to it. The number one benefit of the DOM is that user-facing controls are largely consistent. If I want the user to type text into a text box, I can just use a browser-defined element, and the user will be able to interact with that exactly as they expect. I don't need to reimplement the whole text input and display process, because it already exists in the platform. The same goes for all sorts of controls and interactions, from zooming to select boxes.
Moreover, assuming this DOM is built up in a way where the semantics are embedded in the elements themselves, then it can also be used in different ways. One user might use their browser to render the DOM into something that can see on their screen, while another might use their browser to read the element contents aloud. One person might use their mouse to interact with the system while another might use their keyboard. Accessibility is built into every application built using the DOM - it may not be ideally presented in some situations, and it's still possible to get things wrong, but by default a blind user will at least have a chance of using the system. In contrast, a canvas-based application will need to reimplement accessibility from the ground up (usually in the form of a secondary hidden DOM tree).