What is the preferred method for formatting code?

Between fenced code blocks and indented code blocks, I don't think there is a strong preference either way (at least, not yet), so no one is going to be bothered by your choice on that. It is worth noting that both CTRL+K and the toolbar button still produce indented code blocks (for the feature request to change that, see Should we make the {} button add ``` instead of four spaces?).

If neither format is preferred, why are backticks more heavily emphasized in the help shown to new users and question askers?

Presumably because they tend to be less fiddly than indented code blocks, not requiring changes to the Markdown lines with the code. Another advantage is that with fenced blocks you don't need an HTML comment to change the syntax highlighting.

(By the way, that the Ask a Question sidebar also says "indent code by 4 spaces" is probably a mere oversight.)

TL;DR: Favor fenced code blocks. Like... always.

Might read like opinion, but there's rationale to it, too. On cursory look using either one (code fences or indentation) will have identical effects. So why even care?

I've been pondering about this for while now, and there are in fact differences, subtle, yet with surprising consequences. Code fences satisfy a lot more formatting needs than indentation can. And they are easier to use, too!

Ergonomics

Code fences allow an author to copy-paste code, verbatim. No need to (artificially) indent the code in a code editor, just so that it shows up properly when translated to Markdown. This holds true when initially publishing a contribution, as well as when editing it, so translating a contribution into a format that's easier to edit is an improvement.

There's one unfortunate downside: Depending on the keyboard layout used, the backtick key can be a dead key requiring additional key presses to enter an odd number of backtick characters. That's a one-time investment, though, and if you've written bash scripts in the past you probably don't even perceive it as an investment at all.

There's another ergonomic aspect: The web-based editor has a fairly narrow fixed width. Horizontal space is precious, and using up any of that will inevitably higher the chances of the editor breaking lines of code apart. Navigation suffers, both by keyboard and eye. Fenced code blocks do not use up any of that space for formatting, making it less likely to run into this usability issue.

Syntax highlighting

Code fences allow for specifying a syntax highlighting hint (info string). Using indented code blocks one would need to drop out of Markdown down to HTML comments to specify what language the following (or all) code block should be rendered as.

```cpp
/* Some code */

is far more concise, obvious, and less cluttery than

<!-- language: lang-cpp -->

    /* Some code */

The latter isn't only more verbose, it's also creating a dependency on a particular Markdown renderer implementation. Stack Overflow switched to CommonMark, improving interoperability by agreeing on a common specification. Promoting the latter is leaving an opportunity on the table (see also this comment).

There seems to be a popular opinion that "a language indicator [were] redundant". This assumes that the heuristic used to detect languages works reliably (it doesn't), and will not change over time (it has). If you want to make sure that code renders as desired, and continues to render as desired over time and across different tools, a language tag is required.

CommonMark has a standard feature that suits itself for this purpose (info string). That feature is unavailable for indented code blocks.

Vertical separation

Occasionally it is desirable to provide related, yet distinct portions of code. A C developer may want to post a header followed by its implementing compilation unit, e.g.

/* source.h */
void foo();

/* source.c */
void foo() {}

I'm not aware of a way to produce the identical rendered result in Markdown alone using indentation.

^{Nitpicker's Corner: It is possible to achieve it by placing an empty HTML comment between the two indented blocks, but this is rather a hack and is certainly not obvious to someone unfamiliar with the intricacies of Stack Overflow's Markdown rendering. The solution with code fences is much more obvious and intuitive.}

Recommendation

When authoring new contributions, prefer fenced code blocks with an info string over indented code blocks. It's the only syntax available in CommonMark that supports an author in conveying the desired syntax highlighting applied.

When performing or reviewing edits that change from indented code blocks to fenced code blocks, make sure the following requirements are met:

• Edits remove the (now) redundant spaces.
• Edits include a language tag.

Reviewers can choose the "Improve Edit" option to install those requirements when missing. Extra bonus if you apply vertical spacing as desired.

I will even go one step further and say that an edit that replaces an HTML-comment style language hint with a fenced code block plus info string is an improvement. It both improves interoperability and future-proofs a submission by making it resilient against changes in language detection heuristics.