Sorry if you already got this sorted out, but to go back to the original question, the idea here behind having two lists has less to do with “global” versus “project”, and more to do with having replacements that cater to the Format itself. For example the General Non-Fiction template has some shorthand syntax that expands into figure and table caption numbers. You might think of that as being a “feature” provided by the compile format. The LaTeX project template goes even further, using replacements to help finish building LaTeX syntax that were started by the Styles feature (long story short, I needed to print what the user highlighted in their editor with a style, twice: once in the book as readable text and second as a code that adds the phrase to the book’s index. You can’t print a phrase twice with styles, but you can use styles to set up a replacement that can).
Project replacements work best for things that only make sense to one project, or as a personal preference (presumably saved into the project template you use to start new projects, if you do so). Shorthands for long proper nouns that you need to have fully spelled out, that sort of stuff.
There are good reasons to keep the mechanisms of a format separate from the project. Going back to the non-fiction template’s figure and caption shorthands, we could duplicate that format and change its replacements to follow formatting guidelines that adhere to a standard style guide. The project stays the same, using the “!fig(…)” macro, but because you can switch Formats on the fly, you can now make it print two different captioning styles. So that’s a classic case for a replacement being format level rather than project level.
Moving on from theory, a practical difference between the two is that Format replacements run last. This gives you the ability to override a format replacement by getting to the match first. Going back to the caption example, maybe you don’t want to make a whole variant of the format but you don’t like how captions print. Well you can copy the replacement out of the format pane and paste it into your project’s list, and change it there.
To touch on global versus project, perhaps part of the confusion here is that like I say the separation isn’t so much to serve that goal, and you could even argue that project replacements are kind of the global thing, because no matter what Format you choose in the sidebar they always work. But I feel that’s not a good way to think about these lists, since none of them are truly global (such a thing doesn’t exist, but if it did it would probably be in Preferences somewhere).
The main conclusion is that there is no need to have your replacement list duplicated in both places. It won’t hurt anything, because the format is never going to see an unconverted emdash, since your project converts them first.
A final practical note: much of the above isn’t terribly important unless you are making templates or formats for others. 
We are careful with our stock templates because thousands of people will be using them, but if you’re the only user of your project’s compile settings—don’t sweat it. When I was in full on panic writing mode for the user manual, my two replacement lists were a huge ideological messes that in no way resembled the clean and logical descriptions above. 
I only just recently sorted them all out.
