From what I understand, while the engine itself is compiled, your GDScript is interpreted. The page that you found, packrat, seems to be about rebuilding the engine, which isn't normally part of the export process for an individual game.
This is one of the reasons why Godot supports custom modules in C++, because this allows compiled sections which can be faster.
I'm sure that Godot will be a lot larger than a game written wholly "from scratch", using just low-level libraries and compiled down to the specific machine. But, it's worth thinking about whether that matters in context.
It vaguely looks to me like Godot adds about 20 MB in HTML5 or Android exports, at least. That's a lot compared to game in The Old Days, but for me it's a reasonable tradeoff for all the ease it provides. 20 MB for cross-platform audio alone is probably worth it, and this also gets you inputs, fullscreen options, and so on.
There's a lot of stuff about speed, optimizations, and benchmarking, but I tend to subscribe to "premature optimization is the root of all evil." Unless you have already made multiple games and know that you're going to need to do things that require every bit of the computer's native speed, you'll probably be better off starting with GDScript, optimizing if it starts to get slow, and finally moving specific logic to C++ if you find it's really causing you problems.
In summary - GDScript is interpreted and this does add "bloat", but computers are big and fast now, so don't assume this will definitely be a huge problem.
Of course, if you specifically want to program in constrained environments, there are also communities for things like games on the Raspberry Pi, Arduino, or the virtual PICO-8 console, which can give more of the older experience of having to track all your memory and count your bytes.
I hope this is helpful!