It's best to discuss such things on the forum - generally closed issues are considered resolved, and we prefer not to have extended discussions on the issue tracker anyway (as it actually makes it harder to fix issue reports).
The spritesheeting algorithm has been tweaked and refined over the years, and there are a lot of subtleties and complications that probably aren't obvious. That's not to say there aren't further improvements that could be made, but it is a very good example of a part of Construct that may look simple but is actually very complicated.
For example you may try using an external packing tool to compare it to Construct's output. But if it packs tiled background images on to the same sheet, then it is not possible to use a tiling texture mode. Perhaps it could be done with a custom shader, but when you take in to account mipmaps then you get color bleed issues when downscaling. So Construct exports all tiled background images as separate images with no padding so it can apply the tiling texture mode to those images in the engine, because it has to. If you then compare that to some tool that has packed those images all on to the same sheet, you might think Construct looks needlessly inefficient. But it's impossible for it to do what your external tool has done, because that hasn't taken in to account the necessary texture parameters that the engine will need to apply to different images used in different ways.
Imagine another 10-20 such cases of various subtleties and complications, not to mention that optimal rectangle packing is NP-hard, and you probably are starting to get in to the ballpark of how complicated this area is.
Is there any good reason why C3 doesn't pack everything into spritesheets as big as possible?
In short, the answer is because a bunch of games will then crash due to running out of memory, and that is worse than some projects having a somewhat sub-optimal use of spritesheets. The max spritesheet size setting gives you some control over this, but Construct still avoids using unnecessarily large spritesheets where it's likely to waste a lot of memory, and will prefer to split spritesheets in to smaller chunks.
If you just fill up spritesheets as much as possible, then it's possible a sprite animation will spill over from one sheet to another. At 4096x4096 every spritesheet takes 64 MB of memory. This spilling then means anything that uses that single sprite animation must use a minimum of 128 MB memory for the two sheets. Repeat that in a large project a few times and you can quite possibly double the memory requirement and hit out-of-memory errors. Cue lots of reports of how Construct wastes loads of memory and that it obviously needs to be improved. Spilling also reduces the efficiency of image compression as it spreads similar image content across two different images. Construct tends to put sprites with a lot of animation frames on their own spritesheets specifically to mitigate those kinds of problems.
I guess we could have a bunch of settings to micro-manage how spritesheets are generated, but we have always wanted to avoid such complexity in Construct, as it makes it less beginner-friendly and it is hard to explain what all those settings do, other than "try random combinations to see what works best for you". I suppose we could have one extra setting along the lines of "prefer filling up spritesheets", as for pixel art games perhaps that will produce a better result. But for pixel art games, is the situation really that bad? Modern web serving will serve multiple files in parallel over the same connection probably involving a nearby CDN. So whether it is downloading 40 files or 4 shouldn't really be that big a difference.
Anyway, in short, I just want to highlight that if you think there is one easy way to make everything optimal for all projects, it's really much more complicated.