The most important thing, from the technical standpoint, is that your asset pipeline is robust and can handle weird things. The engine shouldn't consume files haphazardly, it should deal with "built" assets, where you can trace things from the in-game content back to the source file. A configuration layer usually appears to give an in-engine ID to a loaded asset, because files and assets do not map 1-to-1. You can choose to fight the organization battle in that layer, rather than in the file system. When you have a slick IDE like Unity, this is all built into the GUI, but a custom engine can just use a batch process to do the same.
Version control is useful - not a DVCS, because it doesn't scale to binary assets, but SVN or Perforce. Artists will groan about waiting around for the VCS to resolve things and the inevitable problems with locking, renaming, and deleting stuff, but their lives will be better off overall if it's in their workflow loop. It's "10 hours waiting on SVN Updates" vs "30 hours debugging project history".
Here's an article on "import" vs "export" based pipelines, where the thing being "imported" to the engine is a common, standardized format that every tool can export - rather than one proprietary tool the team happens to use: