I’m not seeing any keyed version of the Elm benchmark. Did you mean non-keyed?
Aside from that, I would question how useful these benchmarks are. My understanding of Svelte is that these results require no extra work for the developer, which is not the case in Elm. Where I work, we avoid using Html.Lazy on purpose, because it adds a non-trivial maintenance burden.
The reason is that Lazy uses reference equality in its arguments to determine if anything has changed. This seems reasonable, but unfortunately it’s also different from everywhere else in Elm, which uses structural equality. So if you end up using Lazy abundantly, you get two flavors of Elm: the normal one, and the one where you have to eschew idiomatic practices to preserve object references.
As an example, if you pass a Maybe to Lazy, it’s very important to not use e.g. Maybe.map on it first, as that will create new references on every run, and undo all your performance gains.
I think Html.Lazy is one of those mechanisms that work great in benchmarks. Benchmarks are often small, written by a single person, and rarely change (like the one you linked to). By contrast, code bases like the one I work on are very complex, have lots of churn, and are changed by multiple developers with different levels of expertise. And though we only use Lazy in one place in the application (IIRC), we’ve still seen it break because a developer accidentally did something otherwise idiomatic with some of the input.
So we prefer to pay the performance penalty, over trying to optimize our use of the VDOM. Without being an expert on Svelte, it still seems to me that Svelte has a solid performance advantage, in that their approach is applied throughout the code base, as opposed to how it is in Elm.