You are correct that changing either block size or block frequency would successfully allow more transactions to be confirmed per unit time.
However, changing the block frequency means changing the difficulty adjustment formula. This requires a hard fork just like changing the maximum block size would. In either case, network nodes that do not adopt the new rules will consider the new blocks as invalid, and if not everyone agrees to adopt the new rules, the currency will effectively split in two.
If you are going to have a hard fork anyway, changing block size has somewhat fewer technical pitfalls than changing the difficulty adjustment formula. For instance, increasing the frequency will lead to a higher rate of orphaned blocks, where two miners each find valid blocks almost simultaneously and neither builds on the other.
Also, increasing the block frequency means that "confirmations" would not mean the same as they used to. We think of "6 confirmations" as a benchmark for a transaction that would be extremely hard to reverse, but what that really means is "60 minutes of mining time". If you adjusted the frequency so that the average block time was one minute, now everybody would have to use "60 confirmations" as the benchmark for equivalent security, and all software that counted confirmations would have to be updated. (For instance, think of exchanges that don't want to credit a user's account until their deposits are sufficiently confirmed). Any software that isn't updated will lose 90% of its security against double spend attacks. So this would be more disruptive than changing block size.
Here is an example. The current Bitcoin difficulty is about 6.8e11. This means that an average of 6.8e11 * 2^32 = 2.9e21 hash operations are needed to mine one block. Say you have a transaction in block number 400000 in the main chain, and it has 6 confirmations, so we are now at block height 400005. In order to double-spend, someone would have to create a conflicting transaction in a conflicting block whose parent was block 399999, so the new block would also be at height 400000. Then they have to mine 5 more blocks on top of their new block to get their new chain to be at least as long as the existing one, and hope that future miners will mine on their new chain instead of the old one. So this requires mining 6 blocks = 6 * 2.9e21 = 1.7e22 hash operations.
Now imagine you want the average block time to be 1 minute instead, so you cut the difficulty to 6.8e10. It now takes only 2.9e20 hashes to mine one block. So a transaction with 6 confirmations under this new scheme only takes 1.7e21 hashes to reverse. If you want the same security as before, i.e. 1.7e22 hashes needed to reverse, you have to wait for 60 confirmations.