I use the parameter server for most configuration variables of my applications. The documentation mentions that it's too slow to really use it as 'random access memory' (and the documentation is right), but it's the perfect way to have a uniform configuration over the whole application. For calibrations, I often use separate files (the same way the camera_calibration package does it), but you can do that using the parameter server too (although you should probably think about writing them to disk). Variables I use all the time (or which are used on time-critical paths in the application) are read from the parameter server during initialisation and stored in class members.
I use command line arguments (Boost program-options) only for things that link a general node to a specific device (e.g. a camera node for the left/right/top camera) and for things I want to change while debugging (e.g. log directories, graphical debugging output...). That's a personal thing, but it allows me to use different settings while debugging without accidentally checking in a debug parameter file.
I use the parameter server, calibration files and command line options for configuration and publishers and subscribers, services and actions to pass other data around. Shared memory is an option, but I prefer to avoid it (after some years programming Erlang/OTP, I love how message passing makes concurrent applications much easier to debug than shared memory). Of course, you can also dump data to disk and read it from there or set up your own network or network-like connections.
