Yes, a lot of your patterns here are the same with me. These are the differences:

• I do like a space between the function name and the opening bracket - I find it aids eye-parsing. This is so ingrained now that it irks me when some SQL dialects prohibit it.
• Cuddled elses and elsifs for me. The alternatives just waste vertical space.
• No whitespace when dereferencing.
• I have only just recently started the "all POD at the end" technique and while I can see the benefit it in terms of compilation efficiency I'm still not sure it's better from a dev point of view. Ask me in another 5 years. :-)
• I use the same editor all the time (vim) because it is my IDE.
• I've only used PPI very rarely but that's likely more of a domain-related thing.
• I should use a bug tracker for everything. Habit instead results in a lot of small .txt files littering the place. Or worse, handwritten notes on the backs of envelopes.
• Parameter/argument validation is only done where the programmer deems it necessary/beneficial.
• I used to use pure perl OOP almost exclusively. Recently however, Class::Tiny has been beneficial in some situations in removing a lot of boilerplate. Might be worth a look for you too?

Over the years I have taken on board a lot of what are widely regarded as Best Practices. There are one or two exceptions which I still cling to:

• Don't use /x as a regex modifier willy-nilly, only when there is a real benefit. (similarly for other modifiers but I see a lot of occasions where x is used as a habit and actually has no bearing on the regex at all)
• Exporting symbols by default is OK. If people don't want their namespaces polluted there are easy ways to avoid it in the importing code.
• Implicit returns are fine, especially for subs expected to run in void context. Same for explicit return undef.
• Postfix dereference is just annoying. It's like a surprise twist at the end. Fine in a novel, not in code.