A clean Sitefinity site loads fast on the first request after a deploy. A heavily customized one crawls on that first hit. The difference is precompiled templates, and once you understand the path a template takes through the framework you can stop blaming the hardware.
I asked Telerik support how the precompilation actually works, because I had a site with slow load times and wanted to know what I was fighting. The answer was the clearest explanation of it I have seen, so here it is close to verbatim:
Each of our ASP.Net controls has a template, which has a virtual path. When a request comes for a page that contains this control, we resolve the virtual path and we try to load the control from the Telerik.Sitefinity.PrecompiledTemplates assembly (this is much faster than letting asp.net compile the control). The assembly was made using the asp.net compiler tool and asp.net merge tool against the final build version of Sitefinity. If the requested template is not present in the assembly, we fetch the template from the database, check if it is different from the original, and only then do we use the asp.net framework to compile the control given its virtual path. You can look at the System.Web.Compilation namespace, and more precisely the System.Web.Compilation.BuildManager class and its CreateInstanceFromVirtualPath method.
Read the part about the database check again, because that is the whole performance story. The precompiled assembly was built with aspnet_compiler and aspnet_merge against one specific Sitefinity build, so it only covers the stock templates for that exact version. The moment a template in your database differs from the one baked into Telerik.Sitefinity.PrecompiledTemplates, you fall off the fast path and ASP.NET compiles that control at runtime through the BuildManager.
Every template you customize is a control the framework now has to compile on first hit. That is why the slowdown shows up right after a deploy or an app pool recycle, when those compiled controls have been thrown away and have to be rebuilt, and why it scales with how much of the default UI you have touched. If first request speed is what you care about, the lever is fewer customized templates, not a bigger box.