You're right that ILM does some of the same things that Curator does.
The way to think of it is that Curator is kind of like a swiss army knife: it can do a ton of stuff: you can basically write a yaml that does a completely arbitrary order of actions. I suspect there will always be use cases for this kind of capability. There are advantages and disadvantages to this type of tool: on the advantage side, it can do most everything you'd want to be able to do. On the disadvantage side, the configuration can be long and sometimes confusing, it requires a separate running process, it doesn't have a UI, and it doesn't really encourage users (especially new ones) to use best practices. The virtually limitless configurability of Curator kind of works against those in some ways.
On the other hand, the way to think of ILM is that it's a built-in way to ensure most users are using best practices when dealing with time-series data. ILM knows things about the cluster and indexing that Curator doesn't and, as a result, can intervene in the "right" ways in ways that Curator can't. For example, because the shrink action requires the index to be marked in read-only and that shards should be on the same node, ILM can ensure those actions are done in the right order.
ILM is beta (as of 6.6), but we're quickly moving toward GAing it. I think ILM will be a great way for most users to manage their time-series data and I'd encourage people to use it when they can, since it helps prevent many of the administrative errors we've seen in production systems that try to do time-index management (with or without Curator). For those that need the extra configurability (or if you've got a working Curator setup that does everything you need), there's Curator.