Hockey, I thought that you'd know better than to use home-cooked security solutions!
str_replace(), if used correctly, would unrecoverably damage the original file.
If used incorrectly (i.e. without loop, like in your example) it would damage the file and still leave a hole (Imagine this: <?p
<?phphp)
Depending on how your server is set up there are different possibilities, but the safest bet would be on turning off the php engine for the upload folders (with .htaccess or with apache config files):
The only danger that remains with this setup is LFI - but it's easy to check for it. You can also mitigate it by hiding the real system paths with rewrite rules.
Another often overlooked problem is with allowing HTML uploads - these are XSSes
par excellance!
A simple solution is to serve them as plaintext, but it falls in the blacklisting trap: you'll have to enumerate all possible extensions that all possible browsers may interpret as html, whereas the attacker has to find only one you missed :/
If your applicaton design allows it, I suggest forcing "Content-type: binary/octet-stream" and "Content-Disposition: attachment" for all files.