I would say yes, a little, but no it's not terribly important in most cases. Setting aside one-time deployment cost, there will be additional code to run with each transaction. It's not free, but the additional code won't be especially more expensive to operate in most cases.
Have a look at gas costs per operation (no warranty implied): https://docs.google.com/spreadsheets/d/15wghZr-Z6sRSMdmRmhls9dVXTOpxKy8Y64oy9MvDZEQ/edit#gid=0.
A basic heuristic is that state change opcodes (e.g. SSTORE) are quite high compared to compute opcodes that don't change the blockchain. One can generally add additional low-cost overhead steps (e.g. look up a contract address and form a message) without greatly increasing the overall cost of a state change. The state change will be expensive in any case.
Read operations are often handled with constant functions or local calls that don't use gas at all. So, transaction cost concerns are generally limited to transactions that will result in a state change. So, create/insert, update and delete have a cost (the lion's share from ops like SSTORE). Reads are usually cost-free regardless of complexity. Also consider that many systems use offchain storage fed by event emitters that maintain a copy of "official" facts for performance reasons. Another example of a situation in which only the cost of updates is of any concern at all.
To play around with a specific example and compare costs, you could consider coding representative functions both ways and comparing actual gas consumption. Solidity Realtime compiler will show the bytecode after compilation. You can step over source code to see which actual steps are "expensive" and optimize accordingly.
As a footnote, beware of the hidden cost of additional complexity. While upgradable contracts are advantageous in many ways, there's a yin-yan-like set of tradeoffs to consider for each use-case. For example, upgradability could reduce trustworthyness in some cases and is potentially a new source of bugs.
Hope it's helpful.