Yes. Long running sprocs will kill scalability for any OLTP system, so don't create long running sprocs if you can avoid it. Usually long-running sprocs are the result of really innefficient SQL or when you are doing massive computation in preparation for reporting. In these cases, if I was seeing a performance issue, I would replicate my db and run the reports against the backup instead of the primary datastore - or better yet, I would create an OLAP instance that was designed to handle my reporting needs.
Setting an object=null or object = nothing does not actually free memory any quicker than just allowing the variable to go out of scope. Memory is only freed when the garbage collector can no longer find a path from a "rooted" object to the object to be garbage collected. The garbage collector runs as frequently as needed based on some internal .net rules and is generally impervious to attempts to get it to run more frequently.
If you want the biggest bang for your buck, then uninstall any modules you are not using and remove any assemblies from your /bin directory that are not being used on your site (for example, you will generally only be running one logging provider, so you should not have both the XML and DB logging providers in the bin dir).
Also, if memory becomes a huge issue, you can switch modules over to use disk based caching instead of caching in memory. This is slightly slower than the memory approach, but still results in a faster site than not having caching at all.