* If requirements don't dictate a version of Perl to target, what version do you target when writing code for reuse?

Depends on whether or not it is targeted for CPAN. I try to reach all the way back to 5.005 in my CPAN modules, if possible. In-house, 5.6 is the current target.

* Put differently, what features are you willing to give up for backwards compatible code?

I haven't really had to give up any significant features yet. Generally speaking, you can usually code 'around' anything that isn't targetted to a specific level of Perl in the first place (such as an 'Encode::*' module) or limitted by needed infrastructure (required modules that themselves can't be run on less than a certain version of Perl). But I have both 5.6.2 and 5.8.6 installed on production boxes so I can use a required version if necessary.

* What features/code/modules that break compatibility do you most frequently encounter or have burned you the most, particularly when other, compatible methods would do just as well? (In your own coding or on CPAN)

Most frequently it is gratuitious use of 'require 5.008001;' type perl version requirements in test suites caused by using autogenerated stubs. If your code doesn't explicitly need something only available in a certain version of perl or later, don't do it.

What workarounds or practices do you use to help with backwards compatibility? (e.g. IO::String or IO::Stringy for "in-memory" files

Depends on the target. For 5.005 I avoid 'use warnings' in favor of 'local $^W = 1;' invokations and use 'local' instead of 'our'. For 5.6, I avoid 'Encode' and use 'Unicode::MapUTF8' instead.