It would be beneficial if the compiler issued a warning when a procedure uses a "*" dereference operator within its implementation, but no pointer is passed as an argument in the corresponding function call.
Example
proc/SomeDumbProc(text_data)
world << "[*text_data]"
mob/verb/CallDumbProc()
var/fake_text = "I LIKE EGGS"
SomeDumbProc(fake_text ) //Since I didn't use &fake_text , the compiler should yell at me.
EDIT: Fixed the code example.
As a note, I realize that this is not the best example, since it may be beneficial to have a pointer's value printed (I think??). But I just had a bug where I accidentally didn't pass a variable as a reference, and that could have really saved me a good 40 minutes if the compiler just told me to stop being dumb. Q_Q
But that said, there's no way for the compiler to do what you're asking. This would require multiple layers of inference that the compiler isn't capable of making.
First, it would have to see the * operator in SomeDumbProc() and use that to infer that the text_data argument is a pointer. That isn't the least bit possible, because proc internals wouldn't be generated until a later phase; your CallDumbProc() verb might also be generated before this one, so there'd be no way to reliably use such an inference. What might be possible in place of inferring text_data is a pointer is actually adding an "as pointer" specifier in 516 so this can be stated explicitly.
But even if a var is known to be a pointer, it's hard to see how warnings could be generated from that. In the corrected example, SomeDumbProc(fake_text) is the call, but what if fake_text contained a pointer? The compiler doesn't "remember" from the previous line that you assigned a text value to it; that's a lot of heuristics that are well beyond its capabilities. So the proc call is actually potentially valid, as far as the compiler knows.
The only way you could get a useful warning here would be if a new "as pointer" were used on the proc argument, and "as text" were used on the fake_text var, so the compiler would at least have reason to believe the two are incompatible. Vetting proc arguments like this would require some brand new logic however, since that's also a thing that isn't currently done. My concern with that is the potential to add more time to compilations, but it might not be as bad I think.
So in summary I think there are two potentially useful things to take from this:
as pointer: only borderline useful, and not at all useful without further changes
Proc arg vetting: somewhat more useful, since it might help new programmers discover issues
Additionally, if proc args were vetted with warnings, there's no reason that assignments couldn't be also. But again that could add time to compilation, which I know would drive SS13 devs crazy.