First of all, I think it's vital for web designers to know HTML and CSS. Even if they don't know it well, they should still know it enough to get the basics. The reason I strongly believe this is that the web is an interactive medium. It's dynamic, it morphs, it needs to provide feedback, and it needs to be interacted with. You get none of that when you create a photoshop image. You don't have to account for users having different display sizes, or the data changing, or the UI elements reacting to context and helping guide the user. It's important to have some intimate familiarity with the medium, beyond just using it, to properly build for it.
Making something pretty might be good enough for a splash page, but when it comes to actual UI, it just doesn't cut it. I've run into all these problems over and over again with different designers who won't touch or even look at code. Their designs just aren't flexible or nuanced enough to cover all the dynamic aspects of the web. They might look great, but they are often fundamentally broken.
Knowing CSS also helps you create more consistent web experiences. CSS encourages patterns and re-use, and having consistent pages and UI components also lead to better more familiar experiences. I've been given page designs before where every page had slightly different typography or buttons because they were doing everything in photoshop, instead of something that's actually designed for layout, like indesign.
I think all web designers should be able to conceptually do the tasks that are brought up in the article. Things like moving a button a few pixels, or changing colors, and little things like that are easy to do, and can be taught in a few minutes. I'm not talking about writing new CSS, I'm just talking about tweaking existing properties. Subtracting a few pixels from `margin-left` is easy.
Many print designers might not be able to work a printing press, but they still have a concept of how it works, to the point that their terminology like "leading" actually comes from the inner workings of the printing press.
You bring up a great point that it can be much harder to integrate designers into a development environment than it is when they're writing code for a blog or portfolio. Maybe your CSS is messy, and it's hard to find where styles are actually coming from. However, the time needed to do tiny design tweaks is not trivial and adds up. It can easily be worth it to refactor your code in some cases, both for developer sanity and for better collaboration. Also, testing tweaks in chrome's inspector is not a colossal task and can be taught to designers without too much difficulty.
As for keeping the code clean? If they aren't competent enough to contribute directly to the code base, absolutely do not give them access to origin master! Really, nobody should. Once your team goes beyond just a few people, code review is a must for everything, not just designer contributions.
Now git? Git sucks for non developers. Hell, it even sucks for developers too while you're still learning it. But there are ways around it that are user friendly enough for not super technical designers to still be able to contribute and not destroy the code base. If you use GitHub, have them fork the code base, and then they can use the built in editor to make file changes and add commits directly. After that, you click the "pull requests" tab, then it shows you your changes, and you just click "create pull request". Then it goes to a developer who can then test and approve the changes without any danger to the code base. There's a bit of an initial time investment to get someone not very technical to that point, but I think it's worth it.
Also, it's ultimately demeaning and humiliating to have a developer who has his head thinking about tough programming and architectural challenges to have to break out of his flow to change the value `5px` to `2px`. Menial tasks like that are inevitable in a real world code base, but we should be actively trying to get rid of them.