Proper use of Html.lazy is indeed tricky. It is, however, also key to bringing down the rendering and diffing costs. One thing that Elm could do with no changes to the language or the library APIs is make the equality test in Html.lazy go a bit deeper. The most frequent errors I’ve seen with Html.lazy are people constructing records to pass view function parameters — often because the number of parameters supported by Html.lazy is limited — which thereby entirely defeats the optimizations provided by Html.lazy and instead increases the costs. Going one extra level deep on the comparison would fix this.
The more complicated place to put work would be in not rendering data that isn’t on the screen. To the extent that the DOM (and virtual DOM) size is proportional to the visible data as opposed to the entire model data, the costs of rendering and diffing should be insignificant for most uses.