I think you might need to remember that the goal of your company is probably not to generate beautiful or perfect code. Personally, I think that coding standards (especially strict ones) are more of a micromanagement tool than a useful contribution to the quality of the application. In most situations, coding standards should be extremely minimal.
For example those that argue that having a standard for whether the opening brace goes on a newline somehow increases code readability somehow silly. Consistency is nice, it looks pretty, but can you really argue that it actually creates any additional value to the organization?
As for refactoring: That is just one of those things that it is simply better to ask for forgiveness than permission. Do they actively prevent you from refactoring as you go along? Really? Often I see developers waiting around for a stone tablet from the mountain-top to employ good coding practices like refactoring when they just need to go do it. If your boss is looking over your shoulder and slapping the back of the head when it looks like you might be refactoring, THEN there might be an issue. I've rarely seen a shop, though, that the programmers don't have enough autonomy to do it on their own. Just remember to include time for it in your estimates.
Unit Testing: If the lack of unit testing was creating major quality issues, then I don't think you'd have a hard time selling it to your boss. If it isn't then why are you complaining? Just suggest it, make your case and go on with your life.
The bottom line is that you will need to make your case in terms of the bottom line for the company. All of the things you suggest are just a means to an end, and that end is an application of sufficient quality to meet the needs of the users. If you can't find a justification in terms of problems with the current releases (either quality or time to deliver) then you might consider that you are obsessing on your tools instead of the work product. If you CAN find justification in terms of the final deliverable, just point to those complaints and their cost to the business and tie them to whatever coding practice you can offer that will remedy them.
Bottom line: Don't try to turn your problem into your boss' problem. Take one of his/her problems and explain how you will solve them with better practices.