I agree with @xAlien95; the wrapper here seems gratuitous.
I think of wrappers as value-processing ones (like @Lowercased), which constitute the majority of wrappers, and wrappers used to interface with hidden API (like @Namespace).
Task locals belong to the latter category. Yet, they neither project values through the dollar-sign-prefix syntax, nor do they vend a token through the wrapped value directly — relying on a two-step process of accessing the static property and calling get(), instead.
Sometimes property wrappers are used to emphasize declarations (see @Namespace). However, @TaskLocal requires that the default value be declared next to the property-wrapper attribute adding syntactic weight to that attribute rather than the static property.
Furthermore, @TaskLocal boasts the ability to prohibit instance-level applications with a hidden property-wrapper feature; an internal compiler check, though, could achieve the same (as Chris mentioned) while reducing API complexity.