First, I am going to assume that the "middleware" that you are referring to w.r.t. ODBC will be ODBC driver manager or similar transport software...

The UID (user id) and PWD (password) fields of the ODBC DSN is, by definition, the information that is used by the remote server to determine the credentials of the connection and therefore it does not have any meaning to the "middleware".

This is not to say that someone would not be able to write a piece of software that could do something with the UID/PWD data (e.g. record it in a log file) because this could certainly be done.

So to answer your primary question, in my limited knowledge of the middleware to which you refer, I do not know of any middleware that uses it... other than to possibly record it in a trace log (and even then, the password value is typically written as asterisks so as to not divulge the actual value).

To answer your related question, SQL Anywhere decrypts the SA's connection DSN's encrypted password (ENP) value when the connection is made to the SA server and therefore it knows the unencrypted password value and can pass it to the remote server if needed (i.e. there is no password in the remote DSN and/or no extern login defined for the remote). But note that the SA server knows nothing about what is in the DSN that is given in the remote/proxy server connection - it is up to the ODBC driver manager and/or driver to read the DSN and handle its contents.

The SQLServer connections certainly don't, can't speak for the others.

Just to add a later answer (actually a comment) from Karim on a related question:

The userid and password in the DSN gets overridden when making remote data access connections.

So the answer does fit Breck's expectation (or at least his impression...):

No, the credentials from the DSN are never used, and as a consequence (to cite from Breck's question):

You must either define an EXTERNLOGIN or specify UID and PWD values in the remote server connection string. - If you do neither, it will use the user id and password that was used to make the current connection (on the source or client database).

CAVEAT: AFAIK, this does also apply to remote calls from within stored procedures and the like: It's still the current user (and not the procedure owner) who does make the remote connection - and therefore needs his own externlogin or needs fitting remote credentials (unless the remote credentials are already specified in the remote server connection string).
I'm adding this note as I've stumbled too often over that by falsely assuming the remote call would be made in the context of the procedure's owner (just in the way permissions are checked in the context of the procedure's owner)... - that's different here.