Resize partition to maximum not possible ... bug?

Leaving 1 MiB free at the end of the disk space is needed for the partition table backup copy. This comes from the GPT specification. That 1 MiB space isn't left free, but it is taken by the backup copy of the partition table. GParted keeps it ut of the partition space in order to prevent corruption in case OS writes data in that partition table space.
Perhaps other partitioning programs allow to take that space too in a partition.
For MBR disks, no such space is needed as the partition table is located in the first sector of the drive, and no backup copy is kept. As I remember, there has been in the past MBR software that kept unofficial copy in the second sector but no general rule was about that.

So it isn't any bug, it is a requirement for GPT drives.

As for the initial 2048 sectors, they are the 1 MiB space needed for the MiB alignment. A drive can work with any alignment, even with the old legacy MBR scheme alignment, with a performance penalty and a faster wear out for the SSD drives. The 1 MiB has been chosen because it is multiple of the various cluster size values used by hardware manufacturers (i.e. 512 kiB, 256 kiB, 128 kiB ... ) for the newer generations of their products (SSDs and high capacity HDDs). So, since the mid 2000s the 1 MiB (2048 sector) alignment is used for new systems, GPT as well as MBR.

Of course, your partitioning can be GPT only (no MBR) due to the big size of the drive. The MBR scheme can't make partitions bigger than 2 TiB.

You can find a few more details about the GPT scheme in the following page:
https://en.wikipedia.org/wiki/GUID_Partition_Table
especially at the image on the left upper part.
There are two GPT locations: the primary GPT in logical blocks 1-33 and the secondary GPT (the backup copy) in the last 33 logical blocks of the drive space.
(logical blocks are emulated 512 byte sectors, as we know them from the legacy 512 byte/sector hard drives).
The first block of the drive (logical block 0) contains an MBR-type structure to prevent non-GPT aware tools and OSs to think that the drive is unallocated and so damage the content.

So, the minimum reserved space at the end of the drive has to be 33*512=16896 bytes.
However, in newer hardware the minimum space for hardware blocks is usually 4 KiB, and in some disk types (especially SSDs and various flash type media) the write operations are done in much bigger blocks, as 64 KiB, 128 KiB etc. In order to avoid problems of software compatibility with all these different block sizes, OSs prefer to use the common multiple size of 1 MiB that ensures that each partition is located on its own blocks and no block is shared partially by two partitions or the last partition and the secondary GUID partition table. For the microsoft systems, the MiB alignment for the partitions was introduced with the vista OS.

As I wrote above, the 16896 bytes are the strict minimum for the secondary GPT.
It is possible for GParted to use the existing partition alignment, in case of modifying existing HDD partitioning. You could even use parted from the command line to make any partitioning you want. However you have to be sure that it is compatible with your hardware and that it is safely supported by your operating system, your software and your filesystem maintenance tools. I insist on this point because all these are mostly tested for the usual/commonly used configurations. This "common" configuration is now the MiB alignment that leaves the last MiB free for the secondary GPT for the GPT systems. 
For those 16TB or bigger drives, I think it is much safer to stick to the "common practice".