I voted for Amal's answer and Linmao's comment because they both provide useful information.
It shouldn't be a concern for you in this case because you say the
counter is incremented with
It will not reach the maximum value before an unreasonably large number of transactions. In decimal, 2^256 is 1.1570e+77. Assuming the count starts at zero, it's doubtful there will ever be that many transactions, and someone would have to pay gas for every one of them. That scenario isn't realistic, so the counter is financially and practically constrained.
When doing math, you should always be watchful for overflow/underflow possibilities and be aware that 2^256+1 is 0, like your car's odometer rolling over. Similarly, an unsigned integer 0-1 is a very large number, 2^256.
Think about what bounds or limits the range of possible inputs. For example, if you are accumulating a total of ETH owned by the contract, you might reason that it can't possibly exceed the total ETH in existence. If you aren't sure there is no way to overflow/underflow a calculation, use SafeMath to catch and reject all transactions that threaten to cause overflow/underflow.
Use SafeMath to err on the side of caution.
Consider a habit of using SafeMath in all cases as you iterate over designs. It provides nice safety precautions. Consider not using SafeMath as a modest optimization if you are absolutely sure a given operation cannot overflow/underflow in any scenario.
Hope it helps.