Why doesn't bitcoin place additional constraints on competing block chain forks, other than length of chain? (e.g., time and confirmation count)
My question then is: why doesn't bitcoin specify a maximum duration of time and/or a maximum number of confirmations, after which a competing/forking block is rejected even if it's backed by a longer chain of (secretly premined) child blocks?


Because you can't prove that to nodes that weren't on the network at the time of the attack. Which means that either:


It's possible for an attacker to create a new chain, and if enough nodes join the network while the new chain is the best one, it will lead to a situation where half of the nodes believe that one chain is the best, and half think the other chain is the best.
If you make new nodes trust old nodes when they say that the best chain isn't the real chain, you're now expanding the circle of people you trust to the people relaying the chain, in addition to the people mining it. Before, if two nodes thought different chains were best, you could download both and say with certainty that one was better than the other. If you implemented this change, you would need to decide which node was more trustworthy.



  If this would be viable, then the 51% attack scenario described above would become much harder; and as a result, the amount of time/confirmations to wait for before a transaction can be safely believed would decrease, right?


A 51% attack can double-spend outputs with any number of confirmations. The oft-quoted 6 confirmations figure comes from the Bitcoin paper, where Satoshi calculates that an attacker with 10% of the network hashpower would have less than a 0.1% chance to catch up.