I’m not sure if this is really an answer or not, but here goes …
This would appear to be due to some kind of error or non-compliance in the font itself.
The font varelaround-regular-webfont.woff
is correctly fetched (obviously, since the font does show up) from its location on cdn.sstatic.net, but for some reason, Chrome does not render its bold version correctly. There is, at least sometimes, a difference, but it is not all that clear:

The last line there is bold, the rest regular. You can see that the bold is kind of ‘fuzzier’-looking. (This is a screenshot from Chrome 42.0.2311.152/64-bit running on OS X Yosemite.)
With other fonts, including Orbitron Medium (the font used for the main navigation menu (“Questions”, “Tags”, “Users”, etc.), switching font-weight: bold;
on and off in the browser shows a distinct difference in boldness:
(non-bold)
(bold)
Well … more distinct, anyway, but I’m willing to believe that’s more down to the font than the browser: the level of distinctness between Orbitron Medium bold and non-bold is the same in Chrome as in other browsers. So it’s just Varela in particular, which tends to be a good indicator that the error is in the font, and Chrome is just less forgiving than other browsers.
Obviously, I don’t know where we’re getting our fonts from ultimately; but if whoever packaged Varela Round to the WOFF format that’s read by both Chrome, Safari, Firefox, and Opera (at least on OS X Yosemite) is actually someone from SE, rather than, say, someone from FontSquirrel, then it might be possible to have a look to see if there’s something non-compliant going on somewhere in the WOFF file (and, presumably, in the base font as well).
An alternative solution might be to make a separate @font-face
inclusion call to include the actual bold version into the same CSS font. But since there seems to be only one weight of Varela available, that’s probably not a solution.