The answer to this is simple.
Consistency is of paramount importance.
but it comes with a caveat...
You and you coworker are likely obsessing over the wrong sort of consistency
Implementations are disposable. They can be completely overhauled with varying degrees of ease depending on the quality and comprehensiveness of the test suite. Worrying about things like "Should this be a property?", "Shouldn't thins code use LINQ instead of a lower level construct?" is of dubious value. Its vary hard to tie any measurements to the value of consistency at the implementation level. A much better question to ask at this level is "Does this code work as advertised?". TL;DR implementation consistency is where "little minds" get their hobgoblin on.
Why isn't consistency as important here? Implementations usually have a tiny number of contributors. Most methods are written and never touched again. Of the remaining code the number of methods that have two contributors almost certainly a majority. This pattern continues ad infinitum. In this context consistency just isn't that important. If the shelf life of the code is pretty small(a few years) the gains from aggressive consistency are likely a non-factor.
This is not to say that you should go crazy in your implementations. Rather its to say that a nice, clean, simple design will be orders of magnitude more valuable to your hypothetical future maintainer than silly boiler plate consistency method by method. This takes us to the real point...
APIs are not disposable.
This is all APIs code level, web services, SDKs etc. These must, must, MUST be consistent. The productivity gains from this variety of consistency are enormous for a number of reasons:
If you keep your API's consistent you can create suites of integration tests. These allow developers to freely swap the implementation details and achieve immediate validation. Wanna swap your co-works crap over to LINQ? Do the integration tests run? It also provides validation when preparing to go to production. Because computers are fast a single laptop can preform the work of a thousand testers executing mundane tasks. Its tantamount to increasing your organization's headcount considerably.
When API's are consistent you can make guesses about how to use an API just by following what you've learned about using other parts of the API. This is because the API affords a natural, consistent "look and feel". It means your client's spend less time sifting through documentation. Onboarding is easier and cheaper. Less questions are asked to the people that developed the API. Consistency makes everyone a winner
Why is consistency important in this scenario? Because API's have the exact opposite problem of implementations. The number of people using them is typically much greater than the number of people contributing to their implementations. Small gains from a little consistency are multiplied and costs of maintaining that consistency are amortized.
Consistency is expensive. On its face it lowers productivity. It constrains developers and makes their lives harder. It places limitations on the ways they can solve a problem sometimes forcing them to solve it in a non-optimal way. This is often for reasons they don't understand, are ill-conceived, or they are not privy to(contracts, larger organizational or inter-organizational policies).
Raymond Hettinger made some excellent points in his Pycon 2015 talk regarding using the PEP8 style guide for teams of python programmers. He showed that the obsession on stylistic consistency on a piece of code caused code reviewers to miss serious logic and design flaws. His hypothesis can be summarized as finding stylistic inconsistencies is easy; determining the real quality of a piece of code is hard
The point here is be critical. Identify where consistency is important and protect it aggressively. Where its not important don't waste your time. If you can't provide a objective way to measure the value of consistency(in the above cases "effective headcount", cost as a function of productivity) and you can't demonstrate the returns are substantial then your are likely doing a disservice to your organization.