In truth, they both accomplish the same thing. If you are developing controls for your organization, then putting it in the init will do just fine (as in it will work even though its "technically the place where it should be", but MS has created a method where they expect it to go.
If you are like a Telerik, where you are creating controls someone else will use, then I would definitely put it in the CreateChildControls class. Why? Because, that is what people expect, and that is what MS wants control developers to do. What you have to be concerned with in this situation (especially if the controls you develop aren't sealed), is that someone can override different methods, and like you've seen a lot of people override the init class to make their code work the way they want it to. You always want to avoid a situation where your code mysteriously doesn't work because they forgot to call a base method, and it isn't documented. When you put it in the CreateChildControls method what you are telling other developers is: "I'm probably doing something with creating controls here you want to take note of." I would always think to class the base of that method if I override it.
The other great thing about putting it in the CreateChildControls is that a lot of people probably don't know about it (and the people who do, know what it is used for). So when they inherit from your control and monkey with the Init and forget to call the base Init method, your code still "magically" works, and they don't have to fuss with figuring out what went wrong.
