Ok, a bit more but still briefly.
It is a high cost, high risk, low reward endeavor. First it might seem like all it takes is to change the constant that governs block interval. But there are plenty of places in the code where author(s) directly state that it is not prepared for different block times (guarded with static assertions) and even more places, where such assumption was made silently. Especially parts where stuff happens every block would need to be carefully reviewed. There is really no shortage of work that needs to be done instead of that.
Second, shorter blocks pose more problems with network communication (it is not an accident that with half-second blocks, EOS BPs produce 6 consecutive blocks each during their scheduled time). There is also more overhead.
Finally there is really not that many applications that can't work with 3s blocks but would be fine with 1s blocks (and those that are should really be based on EOS - one of the benefits of having many different chains in the crypto space). If anything, there is higher chance that application actually needs as fast as possible communication, where 1s blocks won't suffice. In such case there are two possibilities. First case: the app does not really need to store interactive data. Like previously mentioned MMORPG. When you are f.e. engaged in competitive PvP battle, server has to take over all communication - it can't go through blockchain (it only needs to be the same server for the battle participants, different matches can be handled by different servers). But in the end data on your exact position in every millisecond of the match is not needed to be permanently recorded. Server just needs to send transaction with final outcome, number of points gained, consumed or exchanged items, rewards given, etc., so other servers of the same app can properly update their state. Second case: when app really needs to record everything, f.e. due to regulatory requirements. Like if you wanted to make stock exchange. In such case the most reasonable approach would be to split the work between independent servers (at most one server per market pair) and either record everything on separate public side-chain(s) linking to HIVE with hashes only and records of finalized trades, or (most likely after filtering bloated HFT activity) put content of temporary side-chain inside custom op transactions (assuming it would fit).
To sum it up: a lot of effort that is better utilized elsewhere, risk of bugs, technical difficulties and in the end it does not really help.