evars and props best practices

I'll let others weigh in here, but with the new features Adobe Analytics continually gets, omitting props altogether becomes more and more enticing. You don't need to worry about having to explain the differences between props and eVars to colleagues - they're all just custom variables (eVars). Pathing for eVars is available in workspace, list vars are way better than list props, and if you need a variable that doesn't persist, you can simply tell an eVar to expire after hit.

In the implementations I manage, eVar1 is always page name, and eVar2 is typically URL just so we have those dimensions and don't have to deal with the weird attribution that the regular page name variable has. I find the eVar page name to be much more reliable, especially as I'm able to use it in link tracking calls (page name is otherwise stripped from link tracking calls).

I'd say duplicating things in an eVar AND a prop used to be a common (even a best) practice but agree with Gigazelle​ that it isn't needed as much anymore, because Adobe is continually removing barriers that used to exist between "traffic" and "conversion" information. Because they aren't needed to get around those barriers any more, I'd say I actually prefer things NOT to be duplicated- having multiple dimensions with the same name can be really confusing to users.

As already mentioned, eVars can do pretty much everything a prop can, but props CAN'T do everything an eVar can.... so in many cases, props just aren't needed. The only reasons to still use a prop for something are:
1, you're running out of eVars and have some data that doesn't need to persist, so you'll save an eVar by using a prop.

2, you do need some of the old pathing reports ("flow" visualizations in workspace are great but they haven't entirely replaced pathing, especially for stuff like "time spent on..." or pathfinder)

I agree again with Gigazelle, that having pageName in an eVar is often necessary (I'd set it to visit, not hit, so that it can apply to custom links), and URL in an eVar is better than a prop because of character length limitations (256 chars vs 100 chars).
I often put troubleshooting info ("D=mid", the DTM/Launch library name or build date, etc) into props just to save on eVars, since those are usually not used for analysis beyond spotting issues.