After receiving responses that did not fully address my query, I decided to delve further into the issue of font-size discrepancies among popular browsers. Here are the three main problems I encountered with CSS/HTML font-size in FireFox, Chrome, and Safari on Mac OS X 10.11.4:

The Constant Font-Size Dilemma

Issue 1: Inconsistency when Changing Font-Family

Changing the font-family should not alter the computed font-size, yet sometimes it does. Regardless of user agent stylesheets, this anomaly persists across all three browsers.

In a base scenario without any stylings applied:

pre=13px
pre(code)=13px
p=16px
p(code)=13px

Various theories exist about potential user agent stylesheet configurations affecting these basic sizes, but the root cause remains elusive.

Following an alteration such as code { font-family: "Courier"; } results in:

pre=13px
pre(code)=16px (Chrome & Safari), 13px (FireFox)
p=16px
p(code)=16px

This unexpected shift in size solely due to changing the font-family raises significant questions.

The Mystery of Relative Font-Sizes

Another issue arises when relative font-size values fail to conform to parent elements' computed sizes. Even after adjustments like code { font-size: 100%; }, the expected resolution does not transpire consistently.

p=16px
p(code)=13px

Similarly, setting code { font-size: 120%; } yields unanticipated outcomes rather than the proportional changes envisioned.

This disregard for parent element influences highlights a disconnect in relative sizing calculations.

The Illusions of Responsive Design

The widely promoted practice of using percentages (em or rem) based on html { font-size: 62.5% } proves ineffective in ensuring uniform sizing across platforms.

Even recommended alternatives such as html { font-size: 62.5%; } paired with different units for individual elements reveal inconsistencies across browsers.

Ultimately, the reliance on pixel-based sizes emerges as a more reliable approach, contradicting common responsive design principles.

While concerns over accessibility may warrant avoiding pixels, inherent flaws in inherited and relative sizing methodologies challenge this conventional wisdom. Relying on a reference pixel concept and browser zoom functionalities could offer viable solutions to accessibility dilemmas.

What causes the font size to increase from 13px to 16px when changing the font family in all web browsers?

It is likely due to the default stylesheet settings of the browser.

I believe the solution is not to overanalyze this, but rather to proactively set the font and font size where needed.

Not exactly sure what you mean by "aggressively," but yes: If you have specific preferences for a style, it's best to define it precisely in your own stylesheet, including font family, weight, size, etc.

In the early days of web browsers, a Netscape developer made the decision to impose his personal font preferences on all users. This led to a trend among young coders who believed it was clever to strain their eyes by setting text sizes smaller than normal. As a result, "monospace" fonts were associated with smaller sizes compared to "sans serif" fonts in Firefox by default.

This discrepancy wreaked havoc on font consistency, particularly in cases where monospace fonts were meant to match serif or sans serif counterparts.

To address this issue locally, one could adjust font size settings in about:config to align fixed and variable font sizes. However, this fix only applied to individual instances and did not solve the problem for all Firefox users globally, rendering the monospace css alias ineffective for this browser.

_{Comment from OP transferred from question to answer:}

BoltClock's response was incredibly valuable. The article referenced by him/her regarding Fixed Monospace Sizing by Eric Meyer provides a comprehensive analysis and potential solutions. It delves into the mechanics of browsers when it comes to utilizing user font preferences, shedding light on some of the perplexing behavior I encountered (such as why the code element appeared to inherit a size of 13px when nested within a p element with a size of 16px: the explanation being that it actually inherits the medium size which triggers the default browser/user preferences).

In my specific case, I discovered that I can eliminate the html { font-size: 16px; } style and replace it with the following:

pre { font-family: monospace, monospace; }
code { font-family: monospace, monospace; font-size: 100%; }

This approach allows for consistent relative font sizing while still permitting users to define their default font size. While Eric Meyers suggests using monospace, serif, I've found that monospace, monospace works effectively and appears more intentional in a stylesheet context (odd yet purposeful, conveying a strong preference for monospace).

The crux of the issue lies in the varying defaults/preferences browsers have for monospace fonts compared to other font types. The essence of "accessible responsive design" pertaining to font size is granting users control over text magnification. However, dealing with multiple font size settings (serif, sans-serif, monospace) presents an overwhelming number of choices for users. Users simply seek larger text for readability, whereas authors aim for consistent relative font sizes at any given dimension.

To potentially assist others, here are examples (in the stylish Eric Meyer format) showcasing how monospace, monospace resolves some of the issues discussed in my subsequent response below.

code:before {
    content: attr(style); 
    border-bottom: 1px solid #AAA; 
    color: #575; margin-right: 0.5em;
}
p {
    margin-bottom: 2em;
}

<p>This is a 'p' element with a <code>'code' element</code> contained within.</p>
<p>This is a 'p' element with a <code style="font-family: monospace">'code' element</code> contained within.</p>
<p>This is a 'p' element with a <code style="font-family: monospace, monospace">'code' element</code> contained within.</p>
<p>This is a 'p' element with a <code style="font-size: 100%">'code' element</code> contained within.</p>

<p>This is a 'p' element with a <code style="font-family: monospace; font-size: 100%">'code' element</code> contained within.</p>

<p>This is a 'p' element with a <code style="font-family: monospace, monospace; font-size: 100%">'code' element</code> contained within.</p>
<p>This is a 'p' element with a <code style="font-family: monospace; font-size: 120%">'code' element</code> contained within.</p>

<p>This is a 'p' element with a <code style="font-family: monospace, monospace; font-size: 120%">'code' element</code> contained within.</p>

Once I faced a comparable dilemma when utilizing monospace, and the dimensions varied between Google Chrome, Edge, and Mozilla Firefox. The discrepancy stemmed from distinct font weights and sizes assigned by individual browsers to standard fonts. To rectify this inconsistency, I incorporated Google Fonts, ensuring uniformity in font sizes across all browsers.