"Got to build a path in my code here, so I'll just use 'join' and a backslash... yeah, it isn't portable, but I'm never going to use this app on *nix, so that's ok..."
"Got to run a test here that uses an external file, so I'll just hardcode the path in the .t file... yeah, it isn't portable, but I've never going to move this project anywhere else in the directory tree, so that's ok..."
My meditation: it takes just a bit more extra effort and time to use File::Spec::Function, to make code relocatable, to make code as OS agnostic as possible.
Because inevitably, there's some chance the code will be ported to a different machine, location, IP, OS, whatever. And if you've written it as portably as reasonably possible, it is Sheer Joy when in ports easily. And when you haven't, it is Sheer Annoyance, and you curse yourself for saving a few seconds back then in exchange for hours / days of effort now.
The XP folks wisely warn against designing in extra functionality "just in case" -- I'm not advocating writing piles of extra difficult code just in case you end up porting your module elsewhere, or posting it on CPAN, whatever. I am advocating using simple idioms (like File::Spec) that don't take extra effort and give you the flexibility down the road.
Because inevitably a successful project will wander across different platforms.
Writing from the middle of an XP-to-Linux port --