Things is a little more complex than the other answers suggest:
Only controls whether activating the feature should fail if the file already exists.
Usually you want to set it to true as that'll allow you to activate/deactivate the feature without problems. But be aware that it'll NEVER update the file content nor properties by itself.
Usually you'll set this to true, so you're able to reactivate the feature. But this comes with the risk of your feature thinking that it got it's file deployed when what really exist is a user file with that url. So you might want to use the value false if your feature cleans up after itself when being deactivated and you want to stop activating the feature if the file already exists.
The attribute is ignored if
ReplaceContent is set to true.
Controls whether activating the feature should revert a customized (Unghosted) file to being uncustomized (Ghosted) AND set properties as specified. May fail if checked out by other user.
Ghosting of files
The attributes above are only in effect when the feature is being (re)activated which probably isn't what's happening to you.
What's happening to you is that when you deploy files to SharePoint using File element in Module elements what SharePoint creates in the Content Database is just a record telling that the file exists in this Document Library but with a pointer into the location in SharePointRoot where the file content is read from. This is called that the file is Uncustomized (Ghosted).
If someone goes and modifies the file using SharePoint UI (or object model) the modified content will be stored in the Content Database and read from here. This is called that the file is Customized (Unghosted).
If the file stays Uncustomized (Ghosted) as most files do, then the mere act of deploying (updating) a WSP with new content will change the file in SharePointRoot and thereby update what is read (used) without the feature being reactivated and this will happen regardless of the value of the above attributes.