For hash-prefixed parser functions this should be fine. For those that can be used without the prefix though, doing this would hide a template with the same name.

That may or may not make a difference. For example, enwiki tends to create wrapper templates at the name that will invoke the parser function or magic word, but there are some cases where a template doesn't match the magic word such as Template:Subst, Template:Lc, Template:Uc, Template:Ns, Template:Plural, and Template:Gender. I have no idea what the situation might be on other wikis.

You might also have to be careful that you don't turn {{Project:Example}} from a transclusion of Project:Example into a transclusion of Template:Project passing "Example" as parameter 1.

Yeah, there's a separate issue (T204370) which I think you've already seen which tries to ensure there is an equivalent hash-prefixed and pipe-separated form for each of the oddball magic words/parser functions. So I don't think I can/should/want to touch the "legacy" forms, if you want uniform syntax use the hash-prefixed alternatives.

Note that there are some parser functions where the : makes sense, ex.: #invoke: or int:, because #invoke: and int: can be thought of as magic namespaces for specially accessing the Module: and MediaWiki: namespaces respectively.

Change 819147 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):

[mediawiki/core@master] Allow vertical bar to separate first argument of parser functions

https://gerrit.wikimedia.org/r/819147

Here's some historical context. The first things that used the colon separator were MSG and MSGNW, which were kind of like namespaces, so it made sense to separate them with a colon. By the time parser functions were introduced as an extensible concept, we had ad-hoc implementations of INT, RAW, NS, LCFIRST, UCFIRST, LC, UC, LOCALURL, FULLURL, GRAMMAR and PLURAL using a colon separator by analogy with MSG. All-caps with case sensitivity was used to avoid conflicts.

When I introduced parser functions, I wanted to get rid of case sensitivity. I thought it made sense to continue to use a colon separator, since it meant that parser function names would only conflict with namespaces, not pages, and there weren't so many namespaces. I think MZMcBride suggested adding the hash prefix so that they wouldn't collide with namespaces either.

I think merging the linked change alone would be potentially confusing for users, since there are many parser functions which don't have a hash, and using those parser functions with a pipe separator will subtly fail. I'm not sure the proposed SFH_OPT_HASH feature goes far enough towards solving this problem. I think I would prefer SFH_NO_HASH to automatically register case-insensitive hash-prefixed aliases, i.e. migrate everything right away. Maybe there could be an opt out (SFH_REALLY_NO_HASH), but I doubt there is a need for it.