It seems to me that there's a more general way of looking at it:

A server advertises services for use by client processes. To do that it
MUST have a known address which clients go to in order the user the
services.

A client doesn't advertise anything and so doesn't need a known address.
There is no way that a client can provide a service because there is no
way to know its address until it contacts a server and starts to use the
 service that the server provides.

This applies regardless of the transport protocol being used to carry
the service. It is fairly obvious in the case of TCP/IP because
connection is non-symmetric: the server MUST be listening for
connections, i.e. requests to the service it provides, but the client
never does. Other examples:

- in the *NIX world a server can listen to a named pipe to advertise an
  service that's not available outside that host.

- An X.25 network is peer to peer in exactly the same way as POTS is,
  but a service can't be used unless there's a process that's prepared
  to accept incoming calls.

- 3270 bisync is the opposite: the entire transport protocol is
  controlled by the server. If that's not running, the terminals
  can't do anything.

- X-term fits the same pattern once you realize that an X server is
  providing display and input services to an application program.
  Another clue is that many applications can connect to a single X-term
  server but no X-term can connect to even one application.

- FTP is the really strange case. When you start FTP, the user program
  (client) connects its command channel to the daemon (server). Again,
  the daemon advertises its service on a known host's port.

  The confusion happens when a file transfer is requested because a new
  data channel must be opened to shift the file contents before being
  closed. If you're running in PASSIVE mode its the same: the server
  returns a port number as part of its ACK and the user program connects
  to that port, reads the data, and closes the port. No problem.
  However, in classical mode the user program sends the daemon a port
  that it wants to listen on and then becomes a server. The daemon acts
  like a client and connects to the user program, sends the file and
  closes the connection. Then both programs revert to their original
  roles

Agreed.

FTP runs on two sessions, a command session and a data session. The
command session is initiated by the client; that part is easy. In
classic FTP, the data session is then initiated by the FTP server.
Because this nowadays typically causes firewall problems at the client,
a new "passive mode" FTP has been defined, in which, instead of
initiating the data session, the server requests the client, via the
command session, to initiate it, "active mode" being a retronym for the
original design. Passive mode must be requested explicitly, since not
all software supports it.

I don't know why they didn't just use a single session with a side
channel implemented in the data format in the first place, unless it was
simply to squeeze out the last drop of bandwidth.

So it may be technically correct to say, in describing how to program
for TCP, that it is always the client, by definition, that initiates the
session. But when explaining to someone who has just asked, "What is
TCP?", to whom "the server" means "the big box in the air-conditioned
room" and "the client" means "my PC", it is a pragmatic truth that "TCP
sessions may initiate with either the client or the server". To tell
him, "A TCP session always originates with the client," will only make
him believe a dangerous falsehood, and explaining the whole situation
runs the risk of making him go all Blanche DuBois on you ("My head is
swimming!"), at least in my experience.

If he needs to know more later, then we can say, "When setting up a TCP
session, the side that initiates it is always called the 'client', no
matter what happens after the session is set up." Anyone who needs to
know that will readily understand it.