I wonder how much of this depends on the environments where one tends to
look at code.  I doubt there's anyone here who doesn't see a biased
sample for a variety of reasons.  Consultants only see the code of
people who hire consultants.  Open source enthusiasts see code that is
developed without the benefit of an institutional culture or mutual
review process.  Average developers tend to mainly see code developed
inside their organizations.  All of this can lead to a profound bias in
perceptions of what "most" Java programmers do.

I don't know your background, Jeff, but it would be interesting use of
an omniscient moment to observe how much effect these biases have.

There are a few recommendations that are obsoleted by Java 1.5 features
(largely because Josh had such a large role in deciding what to change
in 1.5, and he naturally chose exactly those areas where he felt that
Java programmers tend to trip themselves up).  Nevertheless, I tend to
see Effective Java as very relevant in 95% of what it says.  The
remaining 5% is pretty obvious (type-safe enum pattern, for instance).

Since a major point of the book is that they are congruent in most
cases, I suppose that separating the two would actually have meant
changing part of the book's message.

Yes, that is the perspective from which the book is written.  I find the
content far more useful, though, when read from a different angle.  
There is a lot of really good information in there on:

a) The low-level design alternatives that can be chosen when writing
code.  This is often eye-opening to novice programmers who have never
even seen one alternative used over the other.

b) Interspersed in the step-by-step instructions, a nice collection of
all the ways that each design decision affects the surrounding code.  
Seeing a complete list of these effects helps train the mind to make
informed decisions about design.

I find this far more useful than the nominal purpose of the book.  When
I'm asked how to learn good programming idioms and low-level design
decisions, one answer that's near the top of my list is to go through
this book and try out these refactorings on real-life code to get a feel
for their effects.

The stylistic and low-level design benefits of the book are belied by
the opposing natures often found in the text.  That is, often the
refactorings are about how to change from A to B, and then from B back
to A.  By looking at the effects of each refactoring in the pair and the
"motivation" sections of each, it's possible to extract a pretty good
description of when to make one decision versus the other.