In spare moments we would generate the missing tests and, as you might have foreseen, found deficiencies in some stored procedures. Some were minor, some were critical. And someone, somewhere, was relying on inaccurate data, depending on the input parameters for the proc.
I have a few rules also.
Nothing is ever as simple as it appears.
Just because something appeared to work, doesn't mean it did work.
There is a vast amount of "working" code out there that returns invalid results at least some of the time, and very little of it is reconciled against other data that may be correct, or at least have different invalid results.
Just the other day, I saw an existing SQL stored procedure (which needed to return results in seconds) that never got tested on the case that one of the varchar parameters was fed in as blank. As it turns out, not only does it takes dozens of minutes to return results, but, presumably due to parameter sniffing, every subsequent call with even valid parameters takes dozens of minutes until the stored procedure gets recompiled.
This was a simple case of not testing boundary conditions, not believing that it would ever be called incorrectly, or both. Regrettably, it's common.