70 MB für eine Single-EXE ist jetzt noch nicht soooooo groß.
Es ist lange her, als ich für einen Bugfix mit einem alten WinXP mal unser Projekt versuchte ohne Packages/DLLs zu kompilieren.
4-14 MB die EXEn
685 MB inkl. allen eigenen BPL/DLL
256 MB fremd-DLL/BPL + 115 MB Debuginfos (ohne DevExpress)
42 MB die Delphi-Packages
...
macht insgesamt, inkl. DevExpress 
1,58 GB + 900 MB an DebugInfos (Delphi 11)
Eigentlich sollte es mit BPLs weniger Problemengeben,
aber bei DLLs, gibt es nerviges Verhalten, leider im einfachen TestCode nicht nachvollziehbar.
Irgendwo versteckt sich in System/SysUtils/... eine Funktion, welche beim Verlassen einer
DLL-Funktion die Delphi-
Exception in eine Systemexception zurückkonvertiert (vor allem EExternal ala EAccessViolation, EDivByZero usw)
Leider fand ich ihn nicht wieder.
Ist prinzipiell dafür gedacht, wenn eine Exception aus einer Delphi-DLL z.B. in ein C++-Programm durchrauscht.
Grundsätzlich würde dann auf der anderen Seite, wenn es wieder in ein Try-Except läuft, daraus wieder eine neue Delphi-
Exception.
Drum ist auch ein Code ala
Delphi-Quellcode:
try
...
except
on E:
Exception do begin
E.
Message := E.
Message + '
irgendwas';
raise
end;
end;
keine gute Idee, weil hier der geänderte Text wieder verschwinden würde, wenn sowas passiert.
Mit hart verlinkten Packages über einen WebShare .... boar, dank eines Bugs im Windows/Samba, haben wir grade wieder einen Kunden, wo es pro
BPL 1-3 Sekunden zum Laden dauert und bei 355 BPLs macht das dann ............... bis der SplashScreen nacht knapp der Hälfte aufgeht.
Und wer bei Mikrosoft auf die schwachsinnige Idee kam, die
PE-Flags für Caching von DLLs aus Netzlaufwerken/Wechseldatenträgern für JEDE einzelne
DLL, anstatt einmal aus der EXE zu nehmen ..... (bei Fremd-
DLL/
BPL das Flag/Bit zu ändern ... bähhhhhhhh)