For the sake of my own sanity, when I say "method" I mean "method or constructor", since they both follow the same syntax in this scope.
I think you're conflating the boolean flag issue with an (un)named parameter readability argument. There are two separate issues which have some minor overlap (i.e. the unreadability of a long list of unnamed parameters), but they otherwise focus on very different problems/solutions.
The issue with boolean flags isn't method parameter readability, but rather that it's often used as a crutch allowing you to implement branching logic instead of implementing necessary abstractions.
As far as I can see, the issue you're dealing with here (i.e. unnamed method parameters) is independent of the type of the parameter in question.
Just to prove the point, in your given method signature, I can't know whether
Contact is the sender or the recipient of the email either. I can make an educated guess that it's the recipient, but that doesn't change the fact that this is still a guess.
Unnamed method parameters will always depend on contextual inference, and this ranges from acceptable (can be reasonably inferred, e.g.
SendEmail(Contact)) to unacceptable (cannot be reasonably inferred, e.g.
But that line of "reasonable" inference is subjective, and not everyone is going to see eye to eye on that.
If you see a method call which uses parameters you don't understand, and you want to understand them, the logical step is then to look up the method declaration.
This process is made nicer by some IDEs automatically looking it up for you (Rider even labels the parameters as if they were named parameters, which I do appreciate) or allowing you to click through to the declaration; but that doesn't mean that unnamed method parameters should logically be avoided at every single turn.
If unnamed method parameters were a no-go, then the language's syntax in regards to method signatures would need to be dramatically altered. You're trying to cover for something that the language doesn't just allow but it pretty much built on. That's a herculean task if ever I saw one.
If you do implement this "no unnamed parameter" approach, then that's a style guide, and style guides are contextual - generally scoped to your company. If your company bases their style guide on the IDE that they roll out to all their employees, that's perfectly okay.
It is possible that this benefit is lost when the company moves to a new IDE, but the IDE-reliant style guide could be significantly easier to implement and stick to. That's a cost/benefit analysis that is best left up to the business, there's no clear cut objectively superior (and universally correct) approach here.
Style guides and conventions are compromises between developers. If everyone innately agreed on the same style, we wouldn't need to create style guides as there'd be no style clashes to begin with.
Since your coworkers don't agree with your proposed style guide; that means it's not a good compromise. Their argument of relying on the IDE makes reasonable sense (just as much as yours does) - provided that this IDE is used across theb oard in your company, and it doesn't lead to architectural flaws in the code.
I'm no Java dev, but in the case of a language which has the option of using named parameters, that seems to be a reasonable compromise between you and your coworkers' opinions.
However, keep in mind that you're also going to have to draw the line on where you expect a named parameter and where you don't. If
isCompany should be a named parameter, then should
contact be named as well? Why not? What distinguishes the two? And so on...