I think code reviews are critical for sharing knowledge on team projects. It helps keep your team informed about refactors and new functionality, while also giving a space for feedback on implementation (in a critical time, before the code has shipped). It allows a very organic way for people to learn from others (reading code, asking about code, thinking about others' code).
That said, you have to get useful code reviews to see any benefit. To me that means using automated tools to do most of the style checks (your braces should be on this line, no space after this foreach, etc) and having an active culture of not being human-powered code linters when doing code reviews. There is a lot of work that goes into having a team give effective code reviews.
I agree that code reviews can slow down an individual, but the speed up to the team through shared understanding should make up for that.
In my experience the lower level classes increase flexibility, maintainability, and sanity of your css. It's what allows bootstrap to be such a powerful tool for so many products.
Using a conceptually high-level naming scheme won't scale very well as your team and site grows. Eventually someone will say, I need a large rounded button, I can use the .buy class for this contact form. Or perhaps your team is very disciplined but ends up with 10-15 different ways of specifying large rounded buttons.
You'll potentially end up where .buy makes sense in two different contexts which will then increase the complexity of your css:
button.buy {...}
h1.buy {...}
Having .button .button-rounded .button-large helps you keep your css simple allows it to be remixed and reused in ways you haven't planned for yet.
Not to say semantic classes are wrong, I like them, but I have yet to see a system for it that doesn't break down after a certain size for a project/team.
Not always. Different operating systems and browser combos have different ways of rendering fonts. I've seen fonts that look good in OSX in Firefox look poorly in Windows with Firefox (Gentium in my case).
Also these images look like they used gray scale instead of sub-pixel rendering so the differences in pixel geometry should be more or less mitigated.
I'm sure in theory it could look better as actual text for certain setups, but this probably allows them to get the best looking text in the widest amount of configurations.
I think this is really useful when you combine it with vhosts on apache/nginx. On my linux machine I run something similar that allows me to serve static assets, run a local dev server (runserver/flask/unicorn, etc) and have a .dev domain to test with.
You can then combine this with xip.io and be able to share your dev site with others.
I really like seeing companies build out their own style guide libraries. It's such a huge win in terms of maintaining css and keeping it consistent across an entire site/platform. We went through this process at Trulia about a year ago, and the results had a huge impact[1].
Sadly we never released our style guide to the public, but we did open source the tool for building it: https://github.com/trulia/hologram
It tries to keep things simple by letting you use markdown and html to document your css/js inline and then extracting that into a style guide.
That said, you have to get useful code reviews to see any benefit. To me that means using automated tools to do most of the style checks (your braces should be on this line, no space after this foreach, etc) and having an active culture of not being human-powered code linters when doing code reviews. There is a lot of work that goes into having a team give effective code reviews.
I agree that code reviews can slow down an individual, but the speed up to the team through shared understanding should make up for that.