You are also assuming that all miners are fully validating every single block before they build on top of it. Unfortunately, we know for a fact that this is absolutely not the case. Many miners are SPV mining; they will begin mining on top of a block before it is fully validated. With SPV mining, it is very possible that miners will end up mining on top of an invalid block and thus extending the chain for that block and find enough blocks so that its is valid.
The miners who engage in "SPV" mining will only mine on top of an unvalidated block for as long as it takes them to validate the block. These miners are relying on the valid economic assumption that it is not economical to build/broadcast an invalid block, and it will cost a troll miner much more to broadcast an invalid block than it would cost the rest of the network to build upon an invalid block for only as long as it takes to determine that said block is invalid. It would cost a troll miner roughly 13.5-14
BTC to broadcast an invalid block, while it would cost 90% of the network collectively between ~.6
BTC-~.62
BTC to build on top of that block for the amount of time it takes to figure out it is invalid.
The result of this is greater security as this will reduce the orphan rate.
OP - You are describing something very similar to EC (emergent consensus). It should be important to point out that only certain consensus rules are subject to EC in your proposal, otherwise the miners will be able to make *all* the rules, which is probably not something that is desirable.
I would also point out that not all nodes' clocks are on the exact same time (when converted to GMT), so it would be difficult to determine if a transaction has in fact been in a miner's mempool for at least 15 seconds prior to broadcasting a block that confirmed said transaction, so I don't think it would be possible for a node that had received a transaction at the exact same time as the miner to validate the miner had the transaction in it's mempool for at least 15 seconds. Also, as achow101 pointed out (somewhat), if a node receives a transaction 5 seconds prior to receiving a block that includes said transaction, they believe said block is invalid -- this is however resolved by your EC clause.
Another problem is that if someone broadcasts a transaction that gets to miner "A" located in China, and a conflicting transaction that gets to miner "B" located in New York, US, then exactly one of those transactions will get rejected by nodes. This will possibly result in a miner creating a block that gets rejected by the rest of the network, and a potentially long orphan race, both of which is undesirable. The winning chain would be determined by EC after the fact.
I think that EC would probably be better for things like long term changes to demand for block space, and the potential for a one-time large block to account for a temporary increase in the need to confirm many transactions. I don't think that EC is appropriate for the minute-to-minute decision regarding which transactions should get included in specific blocks because miners will too frequently not be on the same page.