I agree with Aaron, if your host thinks 50 MB is enough for typical ASP.NET applications and if they think memory usage should drop to 0 after the request is completed my guess is they don't really host very much ASP.NET and they don't understand how the .NET memory model works where the runtime manages memory and frees up memory by garbage collection. So within application code we don't manage memory, that is we don't have to worry about freeing up memory. Of course the amount of memory used can definitely be affected by application code and how much caching is going on and whether there are memory leaks, but by default we don't really cache very much and we don't use session variables so we are not making excessive use of memory and we don't have memory leaks going on.
Certain things are cached by the runtime, such as the SiteMap, the themes, the Web.config settings but by default we don't cache much else other than Site Settings.
I would highly recommend getting better hosting because you are currently hosted in a memory starved environment that will hurt performance badly by continuous recycling of the application pool. Both Arvixe and DiscountASP provide 100MB of memory and this would give you much better performance. I would also highly recommend if you do move to different hosting to get .NET 4 hosting, there are many advantages in .NET 4 vs .NET 3.5.
Regarding the settings you mentioned, SiteSettingsCacheDurationInSeconds expectsa a numeric value not a boolean and I suggest keep it at the default of 360 seconds which means that site settings are cached for about 5 minutes. MenuCacheDurationInSeconds and DefaultModuleCacheDurationInSeconds are settings that may have been used a long time ago but are no longer used, I will remove those settings from the next release. WebPageInfoCacheMinutes also expects a numeric value, I suppose you could set it to 0 but I doubt that will help much in such a low memory environment. What that setting is used for is keeping a list of physical .aspx pages so that when you create a virtual page it knows if there are any conflicts with the url you choose for a new page vs existing physical pages. Its a little expensive looping through the file system to build the list so we cache it to improve performance.
Hope that helps,
Joe