The default today is half the minimum recommendation from 20 years ago.*
The specific key strengthening algorithm used is Salted and Iterated S2K, which combines the input password and the salt and repeats it numerous times, hashing the concatenation. The actual count value you are using is the number of bytes to continue hashing, so the highest possible value hashes only around 65 MB of data. The default of 65536 is indeed fairly low. Each SHA-256 hash block is 64 bytes in size, and PBKDF2 uses the HMAC construction which calls SHA-256 twice for every iteration (processing 128 bytes), so the default strength is equivalent to only 512 invocations of the hash function! Obviously any KDF that uses that few hash iterations is not going to be particularly secure. The maximum value of 65011712 is equivalent to more than 500,000 hash iterations, which is better.
The problem is not only that the value is too low, but that it is not memory-hard. This means that it's very easy to massively parallelize cracking attempts without running into memory limitations. This is the same issue that PBKDF2 has. A proper alternative would be a memory-hard function like Argon2, but GnuPG does not support that. It is unfortunately limited to S2K. You must use a stronger password.
* I am comparing PBKDF2 and S2K. The minimum recommendation of PBKDF2 iterations was 1k in 2000. If each iteration is equivalent to two 64-byte SHA-256 hashes, then we can consider the S2K count divided by 128 to be approximately equal to a single iteration of PBKDF2. As such, 65536 / 128 = 512, about half the recommendation from 2000.