ERC721Enumerable gas profiling and optimizations

Was curious about gas costs and am wondering if it's possible to optimize ERC721Enumerable when using typical 10K collectible structure of Pausable+Enumerable+AutoIncrementID.

Initial profiling showed base OpenZeppelin minting costs about 70,000 gas and typical collectible about 150,000. Big jumps in keeping track of tokenIdCounter and adding Enumerable.

ERC721Enumerable creates storage structures for the three implementation functions.
totalSupply
tokenByIndex
tokenOfOwnerByIndex

In the specific case of auto-incrementing IDs (non-burnable), totalSupply and tokenByIndex could be calculated directly from tokenIdCounter as it's an ordered counter.

function totalSupply() public view virtual override returns (uint256) {
    return _tokenIdCounter.current();
}

function tokenByIndex(uint256 index) public view virtual override returns (uint256) {
    require(index < totalSupply(), "ERC721Enumerable: global index out of bounds");
    return index;
}

Optimizing just these functions and profiling yields about 30% gas savings over robust enumerable implementation.

Curious if there's any issues with these optimizations and to see what others think. Thanks!