In principle, yes, what you suggest could work, even in your "extreme case". But in practice, if it took very little work to create a valid block, then there would be trillions of blocks created per second (by both good and bad actors), and it would become impossible simply to store or transfer that much data, not to mention trying to sort them into a chain. You'd also have a lot more people stepping on each other's toes by creating multiple blocks naming the same parent, leading to many forks in the blockchain that would take a while to be resolved.

But there would be nothing wrong with altering the difficulty schedule so that blocks get created at a somewhat higher average rate (note that the Bitcoin standard is 0.1 blocks per minute, i.e. one block every 10 minutes, not 10 blocks per minute). The choice of 0.1 blocks per minute was arbitrary and a different rate would work fine. Litecoin, for instance, uses a rate of 0.5 blocks per minute.

It is helpful not to have it too fast, so that most of the time there is at least a few seconds between blocks, and the block has a chance to propagate through the network before a new one is found. Otherwise you get more forks, as mentioned above.

Also note that a common misconception is that reducing the block time would speed up confirmation of transactions. The security of a transaction against double-spend is related to the total work done on top of it in the blockchain, not just the number of blocks. So if Bitcoin increased the block rate to 0.5 per minute like Litecoin, that would mean each block demonstrates only 1/5 as much work as before. To get equivalent security to the current standard of 6 confirmations, you would now have to wait for 30 confirmations, and it would still take 60 minutes.

So while there wouldn't be any particular problem with increasing the block rate (other than those inherent in changing the protocol through a hard fork), there wouldn't be any dramatic benefits either.