At times the mentioning of Driver and App code Size comes up as a goal in and off itself when developing for HE. Remember, this is about code running in HE, other platforms have other concerns and/or constraints.
As a developer who doesn't write fewer lines of code just to keep code size down, but instead focuses on separating the code in re-usable blocks and writing the code using as little as possible of language features known to be slow and inefficient, I can say with certainty that you can very well write an App or Driver that outperforms another app or driver written to be much smaller in code size but doesn't take these other consideration into account. Since the only time there is a "penalty" for large code is when loading it, those few moments are easily recovered in other areas. Yes, ideally there shouldn't be a, measurable, load time when a parent device calls a method in a child device, but that is a system design thing.
I have a parent driver that is 141kB in size, using that driver to turn on lights triggered by my motion sensor driver of 46kB, I have a delay of a maximum of 200ms from trigger event entering the hub to the lights reporting back as on. Using a different and much smaller driver for my motion sensor, I have about the same speed. Using an older, smaller, and not as optimized (still rather optimized) version of my light parent driver it can add 50ms to the total time.
Writing code this way is not always easy when there are no native tools to measure performance and run unit tests, but it is possible.
What I want to say to those that look for a smaller piece of code over a larger one, check what it does and how it does it. Try to measure the time it takes to do what you need it to, the results will probably not be what you expect. Sure, you could write super-efficient and really compact code which outperforms anything else in terms of speed, but how easy do you make changes in such code? What if much of that code needs to be used in 30 different drivers or apps but needs some minor variations to fit?
I know many will have opinions about this, and feel free to have them, but what I talk about above is based on measurable data, not opinion. This is more a reminder, don't judge the code based on the size. Small code size might outperform software with a large code size, but large code size software can also outperform software with a small code size. It is content, not size, that matters.