XeLaTeX font rendering tend to be slightly bolder compared to PDFlatex

Short answer:

• This is an issue specific to PDF viewers on Linux (X11) using FreeType versions ≥ 2.5 (released 2013-06) and < 2.6.2 (released 2015-11). For example, I can reproduce this with evince in Ubuntu 14.04, but not in Ubuntu 12.04 or Ubuntu 16.10. So use a different PDF viewer, or just upgrade (or downgrade!) your PDF viewer.
• Even in a viewer version which has this issue, if you increase resolution (such as if you zoom in the text, or print on a good printer), no perceptible differences should remain.
• Not just xelatex but any use of dvipdfmx embeds Type 1C (CFF) fonts, while pdflatex embeds Type 1 fonts.
• The FreeType renderer used by certain PDF viewers (possibly: qpdfview, evince, okular, xpdf, atril, zathura) has better hinting for Type 1C fonts, but the output was too dark in versions after 2.5 and before 2.6.2.
• Even if you've used pdflatex and got Type 1 fonts embedded, you can convert the PDF to have Type 1C fonts embedded by simply calling ps2pdf on the PDF file (yes), as in this answer.

This is why, even though both documents are supposed to be typeset in Computer Modern, the actual font (the computer implementation of the typeface) is different in the two methods, and certain versions of certain viewers at certain resolutions render them differently. Changing any of those—changing viewer, changing viewer version, changing resolution, post-processing the PDF—should make the discrepancy go away.

---

Font formats

A computer font contains, among other things, information about the shapes of the letters (glyphs). Among other formats, these shapes could be described via:

• a bitmap format: probably used by no one today (except Knuth, who has his reasons)
• TrueType format: the shapes are described by quadratic Bezier curves
• "Type 1" format: the shapes are described by cubic Bezier curves
  • "Type 1C", aka CFF (Compact Font Format): a lossless compaction of Type 1 fonts

The underlying issue at this question has nothing to do with XeLaTeX specifically: it is just that xelatex uses dvipdfmx which embeds CFF fonts, as you can see on the dvipdfmx page:

PostScript Type1

PostScript Type1 format font is supported as in dvipdfm, but they are converted to CFF format (for reducing PDF file size when compression is enabled) and always embedded as a font subset.

And you can see these questions on this site that talk about pdflatex (which embeds Type 1) showing up lighter than something that passes through dvipdfmx: Different font types in pdflatex and latex-dvips-ps2pdf chain (asker prefers the Type 1C output) and Fonts look different compiled by latex vs. pdflatex.

---

Font rasterization

At a high enough resolution, there are enough pixels to closely approximate the shape specified in the font. At lower resolutions, there aren't, and we have the raster tragedy at low resolutions (more).

Even though Type 1 and Type 1C are supposed to be fully equivalent in terms of the glyph outlines, it is up to the renderer/rasterizer in your PDF viewer to take the shape information from the font and actually translate it to a pattern of pixel (or "subpixel") intensities on your screen.

---

This issue: FreeType's handling of Type 1 versus CFF

This exact question (PDFs generated by xelatex appearing bolder than that generated by pdflatex) has been raised on comp.text.tex in January 2016, and though some of the responses there are rather misleading (in particular, Type 1C has nothing to do with TrueType), it points to this 2014-December thread on the tex-live mailing list where the question is fully answered.

The issue is that FreeType, the renderer used by some PDF viewers like evince and qpdfview, uses different code for Type 1 and CFF (Type 1C) fonts. To quote Werner Lemberg, a FreeType maintainer (in 2014 December):

FreeType's weakest point is the hinting of Type1 fonts. While CFF fonts are handled extremely well due to the new engine contributed by Adobe, Type1 still uses the old, original engine that has some severe bugs not resolved yet due to lack of time.

The CFF rasterizer code from Adobe, contributed to FreeType with financial support from Google (FreeType is used on Android too), happened with the 2.5.0 release of FreeType in 2013. You can see blog posts from Google and Adobe. The Google blog post has examples which corroborate CFF rendering being darker even at that time:

versus

Similarly from the Adobe blog post:

Even though the authors of the Google blog post, the FreeType maintainer, and the poster Igor on comp.text.tex above found the rendering of Type 1C superior, some users at the time found it too bold, such as Karl Berry:

CM fonts are rasterized much darker, to the point of nearly appearing to be bold fonts.

The issue was not with FreeType exactly, but with the toolkits and rendering libraries available on the X11 stack, which didn't correctly support "linear alpha blending and gamma correction". All this is excellently explained in this supplement to the 2.6.2 release notes. With the 2.6.2 release (2015 November), they turned off stem darkening by default (at the same time adding stem-darkening support for their earlier native (non-CFF) auto-hinter as well, but turned off).

So the discrepancy should be fixed with current PDF viewers. As said above, I could reproduce the darkness difference on Ubuntu 14.04 but not on Ubuntu 16.10. Nor was I able to see it with evince installed directly on Mac OS X.

---

Minor differences (other than darkness)

Even on Mac OS X under Preview or Adobe Reader, although many people above said they noticed no difference, there are occasional differences on the page (most visibly with kerning) that you can notice if you superimpose the two windows and alternate between the two. This is a lot of fun to experience, but unfortunately it is very hard to show screenshots of those. Here's an attempt, but you should try it on your own computer:

Anyway, these differences tend to disappear (they get progressively more and more insignificant) as you zoom your text, so that each glyph takes up more pixels.

I just opened up those PDFs on Debian Jessie (MATE, LXDE). They're looked exactly same, both pdflatex and xelatex. I think it's an OS/viewer issue..