since I don't know you - maybe my tip is wrong - but if you are a bit like me it maybe helpful.
With "a bit like me" I meant the "late manual reader" - in other words:
a.) Unpack the new device
b.) Add power
c.) Turn it on
d.) Try to figure out how it works
z.) No other solution - read the manual :)
I'm just kidding - but since documentation is not a kind of Stephen King book normally nobody reads all the chapters.
And there is a very important thing "hidden" in the compression documentation - which I wanna point you to because we talked about view state and compression:
An other thing - my number one resource are the samples - and some of them have a "performance chapter".
These chapters normally cover the topics where it's about "telerik specific things".
The main part of optimization (from my point of view) is ASP.NET / AJAX - and very little telerik.
Of course there is something "behind" telerik which helps in performance - but that's the part the developers (of the controls) solved.
They took (take) care of optimized rendering - small footprint and so on.
About your three phases of development - I do it in a similar way - with a few changes.
The first thing - I (almost) always have a running thing - "Prototype design" or how ever you may call it.
Other than with your 3 points I start with an "optimized infrastructure" which means that I initially add compression, caching and things like these to my project. The next is what you told - except that web services, ajax calls and (at least a bit) ajax rendering is present all the way in my projects.
The simple reason for this - if I (for an example) know that a Combobox will be filled often there is no need to do it the "classic way" since I already know that it has to be done via a web service and client binding.
I guess (think, hope :)) this "early implementation" saves me some time in the project.
And yes you are right - optimization adds time / cost to a project. So I tend to do the "high end things" on a late stage - sometimes after the initial release - because that's the time where I can measure the (formerly only predicted) "heavy hit consumers".
Or in other words - I can see from site statistics where the reals bottlenecks are.
For an example - if "change password" would take me 3 hours to win 5 seconds - I wouldn't do it - except it is a site where the users have to change their passwords very often.
A lot of possibilities exist in ASP.NET / AJAX and infrastructure (Database Access and things like this).
There are telerik specific things - a good source are the samples.
And - that's the point where no blog / wiki / forum / documentation can help -- there are always "project specific things" which alow to get better performance with a proper solution.