One-Time binding, why doesn't Blazor need a bind mechanism that only evaluates exactly once

[ChrisSchaller]

A lot of JS runtimes and even MVC, WPF and UWP specifically support one-time binding.
Given the prevalence of this feature, I am surprised that in the issue #31534 justification was requested to explain the request.

Why doesn't Blazor natively implement One-Time binding?

In all the other frameworks that do support it, One-Time binding serves to improve performance, especially for complex binding expressions or functions that take up time to evaluate for changes. So if you know in advance that the bound value is not going to change for the lifetime of the component instance, then you use one-time binding syntax. This was especially crucial in Angular to reduce the page digest cycle time.

In Blazor, the change detection is less aggressive, but if we call StateHasChanged() there might still be some binding expressions that need to evaluate function calls that might know in advance would be unnecessary. The accepted workaround to this is to not bind to functions and instead bind to fields or properties that hold discrete values. But although I understand the reasoning, this ends up in some cases with a lot of boilerplate code that frankly I was expecting we had evolved away from.

A simple relatable example is when devs try to port across the MVC HTML helper:
Equivalent in Blazor for Html.DisplayNameFor() and Html.DisplayFor()

 <div class="col-6">
     @Html.DisplayNameFor(model => P.coor)
 </div>

Labels for fields is a common one-time binding scenario, even if the values change, the label in this case is expected to be constant. If I had implemented this function, how can I, and should I even try to prevent DisplayNameFor from re-evaluating for every call to StateHasChanged(). One-Time binding provided a solution for many scenarios that would otherwise have required specific logic to resolve, cache and retrieve values. So why don't we feel like we need this in Blazor?