What prevents DoS based on near-valid block timestamps? Upon receiving a newly mined block, the block timestamp validation is performed here:

https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L3263-L3270

Q1: As for the second check (block timestamp too far in the future), what prevents a miner broadcasting a block that's near the limit in the future and having some of the nodes accept the block, while some other nodes reject the block? 

Q2: If a part of the network accepts a block and the other part of the network rejects a block (i.e., not record the block it in its blocktree due to invalid time stamp), can the network recover from this in any way?
I'm answering both questions at once. It's not uncommon for the network to split i.e. different nodes accepting different blocks as chain tip. In fact this happens from time to time as two or more blocks are found at the same time by different miners. This gets resolved when the next block is found on top one of the previous blocks. The longest chain is valid.

And a miner can't simply set the timestamp when broadcasting. The timestamp needs to be set before finding a valid nonce. Thus a miner is incentivised to mine with a valid timestamp. If the block doesn't get accepted by the network, the hashrate (and electricity) used isn't compensated.