Code guidelines are black-and-white rules written for a gray universe. There are times and places where any given rule is either unhelpful or outright harmful. Blind adherence to rules can be frustrating, or even maddening, to someone who can see the shortcomings of a particular rule.
I would always carefully consider whether or not there is a real justification for setting aside a coding guideline. Yes, I'm being paid to exercise my best judgement, but by taking a job, I have also agreed (explicitly or implicitly) to try and follow the rules and guidelines set forth by my employer and the managers under whom I work.
In this case, there is a difference of opinion as to which form the simplest and/or most readable. There is only one rule mentioned - "one instruction per line" and no justification offered for not following that rule. Consequently, under these circumstances, I would be inclined to follow the rule rather than set it aside.
Different circumstances would give a different answer. For example, I work in a language with is hybrid object-oriented/functional and in a functional language, "one instruction per line" would probably not be part of the coding guidelines. Keeping in mind, though, that functional programmers can, and do, get carried away by their own cleverness, leaving behind code that can be very difficult to follow.