The "most" you can get is "it won't be broken" and there is no level beyond that. CAST5 (aka "CAST-128") arguably already achieves this to a large extent, since no attack is known on the full algorithm despite some active research for a long time (best known attack appears to be due to Wang, Wang and Hu in 2009 and "breaks", in an academic way, a CAST5 reduced to 6 rounds only, whereas the full version has 12 or 16 rounds). Similarly, SHA-1 has known weaknesses with regards to collisions (and these are "academic", too, i.e. still theoretical), but collisions are not relevant to algorithms for converting passwords to keys.
Thus, switching to AES-256, SHA-512 or any algorithm with a big, mean-looking number, will not give you "more security". It will give you a feeling of safety, in the same way that red cars are often believed to be faster. If that's your thing, then, by all means, use AES -- after all, one point of security is to reduce anxiety. But, scientifically, algorithm switching is not necessary. GnuPG defaults to CAST5 and SHA-1 because this maximizes interoperability with older implementations of OpenPGP.
A minor point can be made, though, about the algorithm block size. CAST5 uses 64-bit blocks, which means that there are some more-or-less theoretical weaknesses if you encrypt a single file with a length beyond a few gigabytes. That's an edge case. If you are on the habit of encrypting huge files, you may want to switch to AES (AES-128 would be fine).
As for the "s2k" parameters: the "iteration count" (with --s2k-count) is meant to slow down dictionary attacks by making processing of the password inherently slow. The higher the count, the slower it gets. So, for security, you want the count to be as high as possible, but, for usability, you do not want it to be too high: a higher count makes password processing slower for everybody, you and the attacker alike. So you should raise the count to as high a value as is tolerable for you on your machines.
Of course, this slowdown factor is a way to tolerate relatively weak passwords. All other things being equal, it is better to have a high-entropy password which would resist dictionary attacks anyway.
