As @smarx said, the increasing gas cost is because of the larger function dispatch table.
You can verify this in Remix by stepping through the execution in the debugger. Here's a screenshot of the contract and how to get to the execution debugger
You'll notice that the contract bytecode has a section that looks like this (annotations mine)
0026 PUSH1 00
0028 CALLDATALOAD (Push the first word of calldata onto the stack)
0029 PUSH1 e0
0031 SHR (Shift the calldata right by 0xe0 = 224 bits = 28 bytes. This leaves just the function selector on the stack)
0032 DUP1 (Duplicate the function selector on the stack)
0033 PUSH4 995ab18c
0038 GT (Check if 0x995ab18c is greater than selector)
0039 PUSH2 005b
0042 JUMPI (If so, jump to location 91)
0044 PUSH4 995ab18c (bytes4(sha3("get4()"))
0049 EQ (Check if selector = 995ab18c)
0050 PUSH2 0299 (If so, jump to the beginning of the function)
0055 PUSH4 c88a82d1 (get6)
0061 PUSH2 031c
0066 PUSH4 d2178b08
0072 PUSH2 039f
0077 PUSH4 fb2f26d6 (testWrite)
0083 PUSH2 0422
0087 PUSH2 0088
0093 PUSH4 054c1a75
0099 PUSH2 008d
0104 PUSH4 11694354
0110 PUSH2 0110
0115 PUSH4 8321045c
0121 PUSH2 0193
0126 PUSH4 90bb7b44
0132 PUSH2 0216
You can see that the selectors are ordered by their selector, with some optimization by doing a little bit of a binary search. This explains the non-strictly increasing behavior of the gas cost.
This is actually a very good question, and brings up a natural optimization; placing pure functions at the end of the table would reduce gas costs for functions that are expected to be called on-chain.
This has a trade-off in that it prevents any sort of elegant binary search as the number of functions increases.
EDIT: I opened an issue proposing an optimization which should address this.