Hey gwc_wd, thanks for your thoughts.
Yes, indeed one of the problems is that the shared host limits CPU time. Definitely that's the source of the 30-second timeout when we encounter it, and it may be that it throttles our usage down, which makes s2m run 'slower' than usual...
And yes: it could be somethign else that makes s2m's js (and css) responses be slow.. but here's what I tried:
using our About page (a single page in WP, with no fancy content):
s2m enabled: ~10 seconds (11s for /?ws_plugin__s2member_css=1&qcABC=1&ver=1.01295432284 and 13s for ws_plugin__s2member_js_w_globals=1&qcABC=1&40ccea69118531334c7d0f76ad6c82f1&ver=1.01295432284)
s2m disabled: ~1s
btw, our site is at
http://friendsofnatureparks.org/ (and the about page:
http://friendsofnatureparks.org/about/) if anyone wants to peek

Locally I did not get this sort of problem so I'm secretly hoping that this will fizzle into some 'oh you are missing this piece on the live server' which makes s2m take this execution path instead of that'
For instance, we haven't placed the SSL cert on the server yet... could that (or something like that) cause s2m to take a slow turn at some point?
Alternatively, ugly workarounds work ok for us: this will be a low-traffic low-content low-complexity site so (for instance) I might grab the css and include it in our base template (then find out where s2m is grabbing it and disable that line).. but I imagine the js is more difficult to 'eliminate' or fake.