It's a valid question. Someone with more experience can probably give a different perspective, but here's what I have to say:
Picking coding standards, styles, and figuring out your whole development workflow for your product is certainly important, and putting effort into planning your code structure will absolutely save you time and money.
But not for the reason of worrying about the size of the executable file. Most bloat in an executable file's size is from debugging symbols, which can be removed in a release product anyway. This will happen whether it's OOP or procedural. If your program uses resources like images or any type of saved data, it's likely that that information will vastly outweigh
the size of the executable itself. Many applications have gigabytes of resources, but the exe file itself is still small. Look at how large apps like visual studio, any modern game, or photoshop are.
Many applications won't have a super-huge exe size, but will have dynamically-linked libraries (.dll files on Windows). Those can add up if you have a lot of them, but it still pales in comparison to any multimedia resources. For example, I just looked at the Debug folder for one of the large codebases of a product we have, and even in Debug mode with tons of .exe, .pdb (debug), and .xml files, the size of the directory is still only 100 MB. The exe files themselves are on the order of kilobytes to a few megabytes. Static linking will increase the size of the exe because it's pretty much like you're combining the dll and the exe into one entity. This could happen whether or not you're using OOP.
I have never heard of an instance where the size of the EXE is the bottleneck or the complaint from the customer. I would imagine on some embedded system it would matter, but I don't know much about that.
But no, the bottleneck is not executable size, in my opinion/experience. The bottleneck is maintenance.
You're going to be reading code and debugging a hell of a lot more than you are writing code. And that's where you or your company has to decide what is the most maintainable code structure. This doesn't necessary just mean choosing between OOP and procedural. Nothing is ever completely one or the other, especially if we're talking about a "multi-paradigm" language like C++. C die-hards will say OOP brings bloat and complexity, and that inheritance especially can be horrible to maintain if done wrong, and OOP die-hards will say C programs tend to look disgusting, be unmaintainable, and overuse pointers and what-not. Not picking a side.
Wikipedia happens to have a whole page dedicated to Criticisms of C++, although I can't vouch for how unbiased it is. https://en.wikipedia.org/wiki/Criticism_of_C%2B%2B
* Many of these criticisms are related to C++ and not OOP itself, so don't go just off that. For example, languages like C# don't have as long of a compile time because of constructs like JIT compilation. Also, the C++ language itself is super complicated to parse.