If you really want to put this on the corporate agenda, you need to convince the person making technical decisions. If this gets on his or her agenda, things will happen. Beware when approaching this person - you've been thinking about this for weeks or months, while it may be quite a new idea for them. It may take a while for things to sink in. Don't expect it will happen quickly, or even the way you think is right. Plant the seeds and tend to them as they grow. Be prepared for resistance among coders too - writing docs, tests and releases are rarely seen as very compelling work, especially with tight deadlines.
Before doing anything though, you need to think about how important this is to the business. To you, it may seem like a very important thing and a complete no-brainer. However, you may not have all the information necessary to make this decision for the business. To the product and business people, the opposite may equally seem like a no brainer. All they care about is that it does the job and hits the market when they need it. Tech leaders are often enslaved to this kind of stuff.
Also, in my experience, many times a rewrite / major refactoring ends up costing too much and producing little benefit in the long run. Old idisyncracies are replaced by new ones and key sections of the code - often most critical to the business - end up scarred by changes around them and not better in any way. Be prepared to encounter people with similar experience and perhaps a bit of resistance along those lines.
Joe Random on the street with a camera is a different proposition. A much more menacing one. First, you immediately know you are dealing with a nutjob, who's focused on you. Second, you don't expect any scrupules from said nutjob, or that he'll lose his job or get in hot water if he misuses the footage - a reasonable expectation for CCTV camera operators.
The difference is accountability.