Was the server upgrade done because the app wasn't performing well enough?
Yes, all the things you describe should lead to a faster experience. That they didn't suggests... (jarring chord) that it's not the platform that has the scalability issue.
You need to profile your application. IIS can serve lots of requests a second without any serious optimization, and it's unlikely you'd have changed any default settings (right?) already, so... that leaves the app. Or the App framework (.Net, right? got compilation debug=false set already?)
As you're on IIS 7 now, my suggestion is that the first place you look is Failed Request Tracing (install the Tracing component), and then hook up a rule that targets any response code (100-599), get the FREB log and look at where the time is being spent (the Compact view is good for this). If you see a module taking a disproportionate amount of time, investigate it.
Look at the web logs - are you seeing more requests than you think you should? (It's surprising how often the answer is "yes" when looking at performance optimization). To the time-taken results indicate that yes, the server thinks performance is slow?
Is there javascript on the page? Could this be a client performance perception problem?
If that doesn't provide enough depth, look at either instrumenting the app, or hooking up a profiler to it, to determine where the time is being spent.
The thing is, if updating hardware has no effect - and it looks like a serious upgrade - you're not hardware bound. You probably never were. Asking for "general speedup tweaks" is not what you need - you need to measure, change, test, iterate. Once you identify the cause, the solution is simple. But you're not there yet.