That would require explicit support by each template processor implementation. The Object#toString approach works independently of the template processor (assuming they all call toString() on the parameters).
Since the string template interface is untyped (parameters are arbitrary Objects), having case distinctions based on the type parameter is fiddly. What if you pass an instance of a class that has a genuine toString() but also happens to implement Supplier<Foo> for some reason? Or if you pass a Supplier<Supplier<Foo>>, will it recurse? What if you pass a Callable or a Future? Will those work as well? This only creates the opportunity for opaque “magic” behavior.
The question was whether string templates will support laziness, not whether whatever the string template is eventually used for supports laziness. String templates supporting laziness would make you independent from what the point-of-use supports.
I think that's the wrong question. String templates don't need to support laziness. It's a well established pattern in Java that laziness is done via Supplier's and it directly solves op's question about logging where the level isn't enabled. This is exactly how logback and other logging implementations handle it now.
Since the string template interface is untyped (parameters are arbitrary Objects), having case distinctions based on the type parameter is fiddly. What if you pass an instance of a class that has a genuine toString() but also happens to implement Supplier<Foo> for some reason? Or if you pass a Supplier<Supplier<Foo>>, will it recurse? What if you pass a Callable or a Future? Will those work as well? This only creates the opportunity for opaque “magic” behavior.