The important thing to remember that using SqlServer / StateServer is not just about scaling out (web farms). Even on one server you can run into problems when just using InProc sessions. Basically when using InProc any sessions that are "live" when the app pool recycles are lost. To put this in context, you may be running a purchase funnel and are storing something in the session that is critical to the process (why that may be bad practise is another conversation). Anyway, if that session information is corrupt / lost then the user won't be able to continue. So the app pool recycles and loses any currently live sessions - so any customers currently in your purchase funnel drop out and are potentially lost.
For that reason alone I'd always recommend running SqlServer sessions at a minimum (even locally). Better architecture generally negates any performance issues. If you do run into performance issues you could potentially look at 3rd party StateServer implementations that I'd should be faster.
If after reading the drawbacks of running InProc on a live server you're still happy to be doing that (they're your reasons, so that's fine) the only thing I could recommend is to change your dev server (or test) to run using SqlState and leave Live running InProc. That way you see any problems in the environment that isn't using InProc and can fix them in a none live environment. Then if you decide to switch Live over, you'll know that it won't need any extra dev effort and everything should be OK.
