Okay so personally I've come to the conclusion that I won't be using suffix or prefix anymore. If you are going to use renaming, use suffix. Prefix makes viewing all files sorted by name do unexpected things if it is mixed with files that aren't renamed. I also sometimes type the name of the function I'm looking for in Windows and if you add a prefix now you need to type "hooovahh_" before everything.
So we've already mentioned reasons to not use suffix renaming. QuickDrop, Right click, and other NI frameworks rely on some naming conventions sometimes and these break. OO override issues, you must have all children classes, in the same package as the parent class. Otherwise overrides won't work until it is installed. So a demo or example VI in the child class will be broken until it is installed if it uses the parents override.
But I have another new reason. I had one package that was 16MB in size and was too big. So I moved a bunch of stuff into it's own package. Well the source expected to find all dependencies without the suffix name. Since it was previously in the same package. But now the functions it calls is in the installed location and the VI names aren't the same. It was looking for the VI names without the suffix, but now needs the VI names with it. This means replacing every VI, VIM, control, class, library, XControl, and every dependency. Scripting helps but still is a pain. If I was never using suffix naming then it would just look for the VI names and loading the installed VIs into memory first, would mean the new package finds the source in memory where I want and a Save All will update code to use the installed location.
And I hope it is pretty obvious changing from using suffix, to not can be a major pain if your libraries are as large as some of mine are. This also means updating all active project, replacing all dependencies to the new ones...also painful.
Jim is right that more consideration needs to be made when editing package source to make sure it links to the installed locations of other dependencies. But editing one package at a time can help with that. And I've seen VIPM gracefully fails to build if a dependency is outside of the source. Once built and tested all is good.