Amortized analysis of binary counter with increment and resetting operations
First, 9th line of increment sets $\max[A]$ to -1 if $i \le \max[A]$ does not make much sense.


It does not make sense because it is wrong. This part of code has been wrongly aligned. It should be

5. if i &lt; length [A]
6.   then A[i] = 1
7.       if i &gt; max[A]
8.         then max[A] = i
9.   else max[A] = -1 // the array A overflows; A is effectively reset to 0. So max[A] = -1.



  Why do we need to put yet another coin?


As explained in the article, the amortized costs of INC and RESET are $\$$4 and $\$$1, respectively.


$\$$4 for INC is composed of


pay $\$$1 to set 0 to 1;
place another $\$$1 on the same bit as credit. The credit on each 1 bit will pay to reset the bit during INC (not by RESET); 
pay $\$$1 to update max[A]
place an additional $\$$1 of credit on the new high-order 1 (If max[A] does not increase we just waste that one dollar). The credit will pay to reset the bit during RESET.

$\$$1 for RESET is


pay $\$$1 to reset max[A]. Note that the resetting of bits From i = 0 to max[A] is paid for by the credit stored on the bits (each bit reset here has a credit on it due to the last $\$$1 for INC).



Added: For your specific question on "another $\$$1 on bit 1", note that the first $\$$1 credit on each bit 1 put by INC is consumed by the "resetting" part in INC itself (just as in the binary counter without the RESET operation). That is why you need another $\$$1 on each, to pay for the RESET operation (i.e., the code From i = 0 to max[A] A[i] = 0). The charged $\$$1 for RESET operation is only for the update of max[A].