This is essentially the thinking behind the 'register' keyword. The idea was to make it possible to mark which variables were supposed to go in registers and which could be stored in memory. That may have made sense back in the 70's, but these days, the compiler's heuristic is usually better. This also applies to the 'inline' keyword. Maybe you're right... but maybe you're wrong and inlining the function blows the cache, etc.
I think the same logic applies to a putative 'unroll' keyword. Even if it's a short-term win, the environmental properties that make it a win are likely to change before the code is retired. To me, that argues for relying on the heuristic.
One note to this is that MSVC has both the usual 'inline' keyword as well as a proprietary stronger '__forceinline' keyword. __forceinline overrides the heurstic and forces the inlining of the function even if the compiler doesn't agree it makes sense. I can see how that kind of compiler-specific annotation might be useful tactically. (ie: You've found the compiler to be making the wrong choice for a specific platform and you wish to overrule.) But not a full-fledged language keyword...