To answer your first question, you only need to include PDBs for a production release if you need line numbers for your exception reports.
To answer your second question, using the "Optimise" flag with PDBs means that any stack "collapse" will be reflected in the stack trace. I'm not sure whether the actual line number reported can be wrong - this needs more investigation.
To answer your third question, you can have the best of both worlds with a rather neat trick. The major differences between the default debug build and default release build are that when doing a default release build, optimization is turned on and debug symbols are not emitted. So, in four steps:
Change your release config to emit debug symbols. This has virtually no effect on the performance of your app, and is very useful if (when?) you need to debug a release build of your app.
Compile using your new release build config, i.e. with debug symbols and with optimization. Note that 99% of code optimization is done by the JIT compiler, not the language compiler.
Create a text file in your app's folder called xxxx.exe.ini (or dll or whatever), where xxxx is the name of your executable. This text file should initially look like:
[.NET Framework Debugging Control]
GenerateTrackingInfo=0
AllowOptimize=1
With these settings, your app runs at full speed. When you want to debug your app by turning on debug tracking and possibly turning off (CIL) code optimization, just use the following settings:
[.NET Framework Debugging Control]
GenerateTrackingInfo=1
AllowOptimize=0
NB This doesn't work in a hosted environment, e.g. ASP.NET.