According to the luatex docs, you shouldn't use fontenc with luatex. People swear up and down that fontenc is incompatible, but I haven't been able to find an example where loading the package causes problems.
(I'm curious about this because it can be easier to load the same base set of packages for pdftex/luatex/xetex, and add fontspec only when handling the latter two.)

I know fontenc is not the right way to deal with fonts in luatex or xelatex, but I'm specifically looking for cases where it's detrimental to load the fontenc package. Do you know of any?

fontenc is loaded by fontspec (you can check this in the log). So in itself the package is not a problem.

But fontenc is a special package: You can load it more than once with different options without getting option clash errors. It will then load font encoding definitions for all the options. E.g.

documentclassarticle
usepackage[T1]fontenc
usepackage[LGR]fontenc
usepackage[T2A]fontenc
begindocument
encodingdefault, makeatletter f@encodingmakeatother

enddocument

will load t1enc.def, lgrenc.def and t2enc.def.

This also is not problematic with lualatex and xelatex.

But fontenc will also set the last encoding option as the encoding default. And quite a number of encodings are not suitable for lualatex and xelatex. These engines need the TU encoding (fontspec sets this encoding). Other encodings can lead to quite wrong outputs:

documentclassarticle
usepackage[T1]fontenc
usepackage[LGR]fontenc
usepackage[T2A]fontenc
usepackagefontspec
setmainfontDejaVuSans
begindocument
encodingdefault, makeatletter f@encodingmakeatother

Grüße, αβγ, Ҍҋ

fontencodingT1selectfont
 Grüße, αβγ, Ҍҋ

fontencodingLGRselectfont
 Grüße, αβγ, Ҍҋ

fontencodingT2Aselectfont
 Grüße, αβγ, Ҍҋ

enddocument

So you can use fontenc in your document (I need it to use chessfonts), but you should be careful to load it so that TU remains the default encoding. This here e.g. is wrong:

documentclassarticle
usepackagefontspec
setmainfontDejaVuSans
usepackage[T1]fontenc
usepackage[LGR]fontenc
usepackage[T2A]fontenc
%
begindocument% wrong, encoding is T2A

Moving the setmainfont resolves the problem:

documentclassarticle
usepackagefontspec
usepackage[T1]fontenc
usepackage[LGR]fontenc
usepackage[T2A]fontenc
setmainfontDejaVuSans
begindocument %encoding is TU now

An Example that Might Bite You

It can cause problems if you load both fontspec and fontenc together. More precisely, as David Carlisle points out, if you combine Unicode with other encodings in the same document—which could happen without your being aware that you loaded both, or even on a document that worked before. Here is an example that loads the legacy Utopia font, which is T1-encoded, but then also tries to load a modern Unicode font through Babel.

documentclass[varwidth, preview]standalone
usepackage[spanish]babel

% Due to a bug in Babel 3.22, we must override the OpenType
% language and script features for Japanese, and several other
% languages.
babelprovide[language=Japanese, script=Kana]japanese

% Implicitly causes babel to load fontspec:
babelfont[japanese]rmNoto Sans CJK JP

% Implicitly loads fontenc with [T1]:
usepackage[poorman]fourier

begindocument
¿Es foreignlanguagejapanese日本 Utopía?
enddocument

Permuting the order in which you load packages can give you many different bugs. One of several problems in this example is that fontspec renders all non-ASCII characters inactive, which prevents them from being correctly translated into other encodings. If you re-ordered commands so that you loaded setbabelfont after fourier, you would instead set the main font to Latin Modern Roman.

The rest of my post is about how to get that broken example to work, so if you only cared about the example of something fontenc breaks, you can stop reading.

How to Combine Unicode and Legacy Fonts

I’m not judging. Sometimes I don’t get to set the requirements.

To fix this example, load luainputenc, which, despite the misleading name, also allows switching between Unicode and legacy encodings on output:

documentclass[varwidth, preview]standalone
usepackage[T1]fontenc
usepackagetextcomp
usepackage[utf8]luainputenc % Needed to mix NFSS and Unicode
usepackage[spanish]babel
usepackage[no-math]fontspec

defaultfontfeatures Scale = MatchUppercase 
newfontfamilyjapanesefontNoto Serif CJK JP[
 Language = Japanese,
 Script = Kana ]

newcommandtextjapanese[1]japanesefont #1

usepackage[poorman]fourier

begindocument
¿Es textjapanese日本 Utopía?
enddocument

A Better Solution

A quick Web search revealed that there are several free OTF versions of Utopia, which is legal because Adobe released a free and modifiable version years ago. Here, I load Lingua Franca:

documentclass[varwidth, preview]standalone
usepackagepolyglossia

setdefaultlanguagespanish

defaultfontfeatures Scale = MatchUppercase, Ligatures = TeX 
setmainfontLingua Franca[
 Scale = 1.0 ,
 Ligatures = Common ,
 Numbers = OldStyle ]
newfontfamilyjapanesefontNoto Serif CJK JP[
 Language = Japanese,
 Script = Kana ]

newcommandtextjapanese[1]japanesefont #1

begindocument
¿Es textjapanese日本 Utopía?
enddocument

This is much less of a hack and supports several features and scripts that the legacy package does not. You should use Unicode when you can, and legacy encodings when you have to.

Note that it is not loading fontenc that is incompatible (fontspec loads fontenc) it is using font encodings other than TU (Unicode). So fontecodingT1selectfont is the real problem, although that is most commonly activated by

usepackage[T1][fontenc}

so it is simplest to tell people not to use fontenc.

In addition to the incorrect characters shown in the other answers, even when you get the correct characters, with the xetex and xelatex formats as distributed, hyphenation will be incorrect as only the TU hyphenation patterns are loaded. You can not load hyphenation patterns into a normal document, only when making the format. So setting things up to get correct hyphenation with T1 (or T2 or LGR...) encoded fonts is tricky, not well supported by language packages and will produce documents that will silently produce the wrong results if processed at another site which does not have the custom formats set up.

The situation is different with luatex which can load new hyphenation patterns as a result of declarations in the document, but it is still tricky to get right and in almost all cases it is simpler to use a Unicode encoded font.