You could mean the style of the architecture of the code, and how easy it is to find the bit that you want to fix/extend.
You could mean how adaptable is the code, is it loosely coupled enough that when you grow and find a bottleneck, that the bottleneck can be addressed without enormous changes rippling through the codebase.
You could simply mean the whitespace, variable names, and very basic structure of a file, and whether it takes minutes for a new maintainer to comprehend a file unknown to them or hours (and it really matters when it's a critical bug that needs resolving).
You can already see from my attempting to understand the question, that one way or the other it does have an impact.
Is style more important than shipping? No. A shipped product with poor style beats the most elegant code base that never shipped or shipped so late that you missed an opportunity.
But bad style (however you define it) can contribute greatly to technical debt which may really hurt you later.
For example, in the world before compiled had warnings for this sort of thing, putting the constant to the left side of the equality operator in a conditional reduced the chances of accidentally making it an assignment operator.
Also, the bug rate is reduced the more code you can fit onto a screen without having to scroll. Coding styles that waste fewer lines probably reduce the bug rate.