It is likely secure, yes, when it comes to SHA-1.
The S2K function, as you mention, simply repeatedly inputs the 8-byte salt and encoded passphrase into the ongoing hash function until a certain number of bytes has been processed (the work factor for this function). Then it produces a key that is smaller than the hash output size.
Now this output is an AES key, and we can assume that this key cannot be retrieved, nor is it stored. As you control the salt and secret key, it is impossible to use the collision weakness of SHA-1: even a collision in the output of S2K would be useless. Similarly, a pre-image attack on S2K is useless as well, as the output of the S2K hash is simply not available.
The only possible issue could be that SHA-1 is shown to have such short cycles that multiple inputs could produce the same S2K output. In that case it might be easier to find a matching input, as multiple input values would match. But there is the salt, the relatively short password, the high cycle size of SHA-1 etc. that makes this highly unlikely; this is really grasping at straws.
That all said, S2K is far from perfect. SHA-1 is easy to put in hardware (if it is not already there in current CPU's), S2K doesn't use memory to make e.g. hashing password on a GPU or other specialized hardware tough.
The biggest weak point is and remains the password. I'd rather spend my time making sure that the user is pushed really hard to use a strong password. Because if the password is much smaller than 50 bits then all the cryptography in the world is not going to matter.
Dictionary / brute force attacks on the password will always be more efficient, basically. Spend your time avoiding those.