Security Risks with having Test Stored Procedures that have SQL Injection Vulnerability
One of the biggest IT security misconceptions people have is that there is little or no risk if the system is not public-facing.  There is certainly less risk, but there is still a huge amount of risk because many breaches are coming from within the attacked network.

Assume that your network is infiltrated by a hacker by gaining remote access to a workstation.  From this workstation, they can then launch attacks on all of your systems, not just the public-facing ones.  All of the millions of phishing attempts that are made each day would not be occurring unless some of them were successful, so you have to acknowledge that this type of infiltration does happen, and could happen on your network.

If a hacker were to discover this stored procedure, they could then add objects to the test server, which could possibly end up being promoted to the production server.  You have to assume that once you have bad code somewhere that it can spread.  The fact that there is a SQL injection vulnerability seems to indicate that your developers are not as concerned about security as maybe they should be.

How much damage could be done and how easily would depend on how many other security vulnerabilities exist.  It's certainly unlikely that a hacker would be able to find this stored procedure, but it's certainly possible if they are sniffing network traffic and your client connections are not encrypted.  And how secure are the servers that are calling this stored procedure?  You have to assume that the test code could be decompiled, which would allow someone to discover it and how it's used.

Another misconception is, "there's nothing important on this server."  That may be true, but it could be used as a bridge to servers that do have something important.  The current line of thought is that your network will be breached and there will be damage, so every system has to be locked down as much as possible to minimize the damage.

And as you mentioned, a less-seasoned developer might see this and think it's an acceptable practice, and then some emergency code that is not properly reviewed ends up in production.  So it certainly can be seen as setting a bad precedent.