Keeping the "required confirmations" at 15 would be stupid (anyway, nobody can tell a merchant or exchange how many confirmations he should require).
If a cryptocurrency with a 60-second block interval changes to one second, and all other parameters (reward rate per minute [not per block!], coin price, difficulty) remain the same, then you would need about 60 1-second-onfirmations to achieve a similar security than with one 60-second-confirmation before. This is because the security of a transaction isn't bound to the number of confirmations alone, but also to the "attack cost". This is the cost to revert the confirmations for a malicious miner. And the attack cost to revert a 1-second-block would be approximately 1/60 of the cost to revert a 60-second-block.
There is only one scenario in which a 1-second-confirmation would make sense: for micropayments. Because even an 1-second-confirmation is still better than no confirmation at all, as the act to "add a transaction to a block in the blockchain" is providing already a minimal double-spend protection. And I guess nobody would try to 51% Bitcoin for a coffee (you may be unlucky, however, if the attacker tries to scam several merchants at once). But for larger transactions, you would have to require a sufficient number of confirmations to ensure an "attack cost" high enough to disincentive an attack on your transaction.
Low block intervals are cool for sidechains, and regarding PoS coins the math is a bit different as the attack cost doesn't depend on hashrate - however, they have the Nothing-at-stake problem.
https://blog.ethereum.org/2015/09/14/on-slow-and-fast-block-times/And if I may simply quote Vitalik's conclusion...
The conclusion of all this is simple: faster block times are good because they provide more granularity of information. In the BFT security models, this granularity ensures that the system can more quickly converge on the "correct" fork over an incorrect fork, and in an economic security model this means that the system can more quickly give notification to users of when an acceptable security margin has been reached.
Of course, faster block times do have their costs; stale rates are perhaps the largest, and it is of course necessary to balance the two - a balance which will require ongoing research, and perhaps even novel approaches to solving centralization problems arising from networking lag. Some developers may have the opinion that the user convenience provided by faster block times is not worth the risks to centralization, and the point at which this becomes a problem differs for different people, and can be pushed closer toward zero by introducing novel mechanisms. What I am hoping to disprove here is simply the claim, repeated by some, that fast block times provide no benefit whatsoever because if each block is fifty times faster then each block is fifty times less secure.
)
