In SSH, for all algorithm classes (encryption, MAC, key exchange and public-key authentication), the client and the server send to each other their lists of supported algorithms; the client lists are ordered by preference, and that preference is honoured: the protocol is such defined that the chosen algorithms will be the first in each client list that also appears in the corresponding server list.
I recall that point because it highlights what this "warn below here" option really means. It means that there are some algorithms that the human user would really prefer not to use -- but, for some reason, he included them in its list of supported algorithms. So what will the human user actually do if he gets the warning ? Will he click on "OK, I got it" and proceed with the connection ? Or will he bail out ? In the first case, the algorithms are thus functionally supported, while in the second they are not. Does it really make sense to have a warning popup under these conditions ? If the user does nothing else about the warning than deciding whether to keep connecting or abort, then the warning is meaningless; it would be simpler and safer to simply omit from the list all algorithms that the user is not ready to use.
The warning is useful when the user (on the client side) can, at some point, alter the configuration of the server. It can then serve as a indicator for a misconfigured server, that the user may then fix himself at a later point.
All of that being said, there are reasons why some algorithms are preferable to others. In no particular order:
Protocol version should be SSH2 only. SSH1 has flaws, and if the server you are trying to talk to supports only SSH1 then it is very old software which is probably riddled with unfixed but known vulnerabilities, so you do not really want to connect to that server at all.
DES uses a 56-bit key (officially 64 bits, but 8 bits are ignored in the process, so effectively 56 bits). This is in range of exhaustive search by attackers with a bit of budget (in the thousands of dollars, not in the millions) so you really want to avoid that.
RC4 has known biases. SSH can support some variants that discard the first 1536 bytes of RC4 output, which removes the biggest biases, but not all. While there not has been any published practical exploitation of RC4 biases in the context of SSH yet, this is still a worry and it is recommended not to use RC4.
Blowfish and 3DES are 64-bit block ciphers. In SSH, they are used in CBC mode, which means that they begin to run into trouble after encrypting about 232 blocks (of 8 bytes each), i.e. about 32 gigabytes. If you occasionally transfer gigabytes of data over a single connection, then you will want to avoid 64-bit block ciphers, and concentrate on 128-bit block ciphers like AES.
3DES is slow in software. This may matter if you have a fast network (gigabit ethernet) or very slow hardware (not a PC).
If you have the choice, prefer "modern" encryption modes like GCM or CTR instead of CBC. The mode describes how the block cipher will be used.
For key exchange, you may want to avoid the "group 1" which uses a 1024-bit modulus. Breaking Diffie-Hellman modulo a 1024-bit prime has never been done in a public demonstration (current record is a 596-bit modulus) but it is within technological reach of mankind (projected budget would then be in the dozens or hundreds of millions of dollars). The "group 14" is a 2048-bit modulus, which is fine.
"Diffie-Hellman group exchange" is DH in server-chosen parameters, and normal servers will take care to select parameters that at least match the strength of their authentication public key. So this is safe as long as the server (or its administrator) does not do anything stupid.
RSA key exchange is pretty rare, because it involves generating an ephemeral RSA key pair on the server side, which is relatively expensive. Usual servers do not do that.
So my advice would be: remove all symmetric ciphers that are not AES; keep only DH group 14 and the "DH group exchange"; don't bother with the "warn me" limit; instead, use the failure to connect as a warning. If you cannot connect to a given server with sane parameters, then something is amiss and you should pause and think -- a forced abort is more likely to make you think than a simple warning popup. Maybe the lack of AES support for a given server is normal, but this requires an explicit decision, not a popup that is to easy to ignore.
