EDIT: I'd encourage the HN community to look past the technical merits of the code, and focus on the idea presented (and even perhaps fork and contribute back an improved version).
Scenario:
Attacker sends you harmless looking link to a page that contains some invisible JS that sends a request to localhost and pins kiddypon on your IPFS node. Attacker then sends the police to you.
That's a very big "if" right there. The same could be said for nearly every security flaw ever—if it were programmed correctly, it wouldn't be a security flaw. The reason people harp on prepared statements is not because you can't be secure without them, but that it's much easier to be secure with them. One you have to think about all the time (do I need to escape, do I not need to escape), while the other is almost completely secure against SQL injections by default. Same thing with using system() vs execve()[1]. One is a minefield of quoting issues, the other has none.
[1] Or multi-arg system(), like in Perl or Ruby.
It's really easy to program them incorrectly, and as a result the approach is less secure than just using prepared statements.
There does seem to be a "cargo cult" attitude to PHP amongst a large part of the tech sector.
I just think that languages like c and especially c++ do not get their fair amount of laughter, that php gets.
PHP adds complexity and therefore adds fragility and insecurity. Running PHP ipso facto adds insecurity to an environment.
There are many ways to do web programming that do not add server daemons or listening ports, or long running processes, or additional logins, passwords and management interfaces.