There is no such direct relationship paradigms and executable size, mainly in absolute form. And it confuses two different things also unrelated, after all the imperative is certainly a paradigm, and object orientation is perhaps not, at least some do not consider so, but if it is a secondary paradigm, so much so that it is used along with another paradigm, almost always the imperative. Understand that there is the algorithm that is usually imperative (there are some languages that follow the functional, pure almost none, and very rare other paradigm) and general organization of what is written and assembles the data structures and where the algorithms will be, which represents at most a secondary paradigm, if it is a paradigm.
An example of object-oriented so-called language has not been cited, but it is almost certain that it is imperative in most of what you do, so there is no such dichotomy. I will consider that you are talking about the procedural use that would also be a secondary paradigm of code organization and not how to write the code itself. So...
A procedurally written application generates a smaller executable than the same object-oriented written application?
The part that takes care of the data structure usually disappears when the code is compiled, this part is only used to help assemble the algorithms. It is important to note that the executable usually only has the algorithms.
It is possible to use metadata to give more information wealth to the executable and facilitate reflection activities, then using a reflexive secondary paradigm will be more responsible for the growing executable than object orientation which need not necessarily be extra code generator.
A lot determines the size of the executable
Other forms of programming, architecture, and a number of influences will determine much more code size.
This business of imperative language and object-oriented language is another thing wrong. If they are programming styles you can use one or the other in any language, then that way of looking at languages is wrong. You can program object oriented in C, then the comparison became more difficult.
It is even worse because the size of the executable is often determined by the size of the Runtime and standard language library, in addition to how this is used. For example, C almost always doesn’t need much use in the executable because its library is already in the operating system and will be loaded dynamically, so it seems that it is tiny and not quite so. Of course the total sum is still small because C is minimalist, but this has nothing to do with paradigm. And although it is not part of the executable the Runtime is there in one piece even if you don’t use it all, in code linked statically can save by taking only what you need to use (more or less), but then the comparison is fairer with languages that can not count on the Runtime in the operating system and that has some advantages also.
Comparing similar languages
So we can compare C to C++ which are very close languages, something until unique to happen. C++ has an ever-larger executable, even if you make 100% procedural use, and although the difference is small, it is even larger if you only use C code in the C++ compiler. Have you noticed that there are other things that influence? But if you look at the use of the same procedural and object-oriented code the second one will be a little bigger, at least in my experience. I am not saying that it is not possible to stay the same or until the OO is smaller in some circumstances, is that in practice the way of programming becomes another.
In fact having more small methods helps the code get bigger. But if the compiler is good it will linearize most of them, but certainly not all of them, and this minimizes the problem.
If using a polymorphic form in the procedural can occupy the same or more space than in OO. Using polymorphism can in some cases save space than an algorithm that solves in Runtime something a language can solve in compilation (some cannot do this), but it also has polymorphism that is solved at compile time and increases the code size well (but this is meta programming and not object orientation).
Other languages are more difficult to compare because they have several other commitments, so I finish as I started, this comparison done fairly does not make sense.
And the size of the executable is very unimportant.
I think to go beyond this is to get out of focus and if you need to know more, now you have subsidies for new questions, because it could become a chapter in a book.