Personally, I dont think any “really” needs 24 rotations of blocks. What I would like to champion, is instead that a large sub-group of the block types have their textures “randomnly” orientated (currently top/bottom are the same, and each of the 4 sides is the same orientation), we could set the orientations such that you can have the “pattern” of the block be at any rotation you want on any particular single facing direction (you just cannot control what orientation the other 5 faces end up as), and requires 4 rotations of the block to achieve that.
Aka we dont need a humongous migration of data, or to suddenly lose a MASSIVE scope of block-ids, and we dont have to actually change any system. AND this can even have a rotation tool which rotates the face of the block you click on so for whichever face you choose, you can set its rotation to whatever you like (but again, you cannot control what happens to the other 5 faces at the same time).
Technically, this wouldn’t actually be “rotations” but a re-arranging of the faces so that it works out as being able to rotate a single particular face (without caring what happens to other 5 faces).
Downside being that there is no way to “migrate” worlds to this new format in a way that would be pleasing to the eye in all cases, large amounts of the world would “visually” suddenly get rotated, and existing manually rotated patterns would get jumbled up in most cases, so people would have to use the rotation tool to patch up anyway that changed badly from their viewpoint.
As to why we are not doing work to allow all possible rotations on blocks right now:
The game supports 4 rotations of blocks. Being able to have any rotation (a pre-requisite of even having a tool that can manipulate the rotation in any way that any user has every suggested) would mean having 24 rotations (off the top of my head) or 48 if you include mirrorings rather than pure rotations.
We already have “no” space whatsoever left in the block metadata, and the 4 rotations of blocks are actually implemented by using 4 entirely seperate block-type ids instead. square/bevel chisseled block-variations are also another block-id too, so in fact most of our blocks currently use 12 block-ids each (4 rotations of 3 sub-shape types)
We have 15bit blocktypes (so max id is 32767), and currently use 10748 of them.
Not “every” block is rotated eg grass blocks which occupy over 9000 block-type ids already (each combination of dirt/dirt-color/grass is an independent blockid and even different height of grass is in the blockids, as the block-meta is already saturated by slope-type data, and the block-color already occupied by the grass color, so defining which dirt and which color of dirt is under the grass has to be put into the block-type id), so in terms of rotateable blocks we currently have roughly 1748 block-ids in use (so about 145 block types) .
Going up to 24 rotations, would mean those 145 block types suddenly require 10488 block-ids instead of 1748, which would take our current maximum allocated block id up to 19488.
Now 19488 “is” still in range, but we have suddenly lost " A LOT " of space for new blocks to occupy, and would only be able to have another 184 blocks roughly assuming each is rotated/chisellable. … but if you wanted mirroring of the blocks, and not just rotations, we woudl need 48 * 3 blockids for every block… and now we dont even have space for them all any more without even adding new blocks!!
Now, actually making this all work requires a humongous migration of the every chunk/item/inventory in the game as every single blockId suddenly gets massively re-distributed, and we’ve even had to do this twice already during the introduction of the bevel/square chisels, so not impossible, but a large amount of work, and quite frankly, we have more important work to do right now! (And as I say, I would much rather have the more limited system I suggest at the top which apart from being minimal in implentation time, doesnt waste such a huge amount of block-ids).