If there are automated tools, they should run on the entire asset directory and dump to a new directory in whatever hierarchy makes sense to the tool. When that turns out to be slow, check "file modified" timestamps in the tool instead of dumping required knowledge on the artist.
Getting artists to actually use source code control instead of having personal folders full of things like rock01_retouched_new_final_final.3ds is a bit of a pipedream, but you can at least put the asset directory under source control and make that the only way to see things in the engine.
BS. Just hire better artists. It sounds like hand-waving, but I've worked with both kinds of artists. You're building games, so if you focus on only hiring artists based on their portfolio you might end up with a bunch of stubborn artists who need to be hand-held and worked around constantly. If instead you focus on hiring artists who are good at art AND who can demonstrate a propensity or desire to learn new workflows and and to be flexible, then you'll end up with a bunch of team players.
This is a common complaint about artists, but it has more to do with culture and expectations than anything else.
- Really good binary performance(light years ahead of git).
- Proper locking for files that can't be merged(basically everything in the art dir).
- Proxy support for co-located teams.
Also it's very slow for small files, and the filtering is according to file extension.
So e.g. if I have some massive mp3s for (sometimes many minutes of) music but also many (100s-1000s) small ones for sound effects downloading 1000 small mp3s take a couple seconds per file even if each is only ~40kb big (normally download rate is a couple MB/sec).