Leaks memory, probably due to the implicit function being called to produce the next value. Also leaks with an explicit function, or any other form of loop around it. (We know the sequence is terminating even if Rats aren't exact, because the implicit form turns the match into an inequality. In any case, one can sum the series and print it out each iteration to be sure.)

Still present on Rakudo version 2016.12-315-gdaf7e5185 built on MoarVM version 2016.12-113-gd1da1bac.
Though to avoid a warning, you now have to write it like this:
loop { sink (0, .1 ... 1000) }
Also, while the memory leak that remains *after* each application of `...` may be the bigger worry, I think it shouldn't even accumulate memory *during* each iteration of `...`.
Compare:
1) The following program uses 39.7 M of RAM shortly after starting, and still 39.7 M one minute later:
.sink for 1..*
2) Whereas the following program uses about 52.4 M shortly after starting, and then keeps steadily accumulating RAM usage for as long as you run it (about 137.1 M after one minute):
.sink for 1...*
(Same problem for `1, 3 ... *` or `1, *+1 ... *` etc.)
Brad Gilbert on Stack Overflow <http://stackoverflow.com/a/41670048/1160124> suggested that `LIST, CODE ... END` caches the whole sequence internally, in case CODE reference it.
But couldn't it simply look at the arity/count of CODE to know how many elements it needs to keep in memory?