I’ve never heard of those. Do you have a link explaining them?

C# inherited it from Delphi, so there's plenty of experience showing that this is not an issue in practice. Thing is, if you don't have accessor methods (or some equivalent syntactic sugar as in D) in a OO language, you end up with them anyway, just ad hoc like Java's get/set methods. And then you still have to think about which methods that look like they're pure queries might actually mutate shared state.

If anything, I would argue that explicit accessors make it clearer because in e.g. C# you can't write a method that looks like a getter (but mutates state) by accidentally naming it as such. If someone made something a property, that's because they thought its semantics are property-like, which includes not mutating global state. Sure, people will still get that wrong occasionally, just as they run mutating "get" methods, but it is surprisingly rare.

C++ Builder also has them in their extensions to C++. My guess is that it looks convenient for languages that have a de facto GUI framework/library. In Delphi/Object Pascal, C#, C++ Builder, it becomes convenient to, for example, change a button's text as if assigning to its text value. And it is often taken for granted how the form's UI just "magically" updates. I'm pretty sure classic VB's control "properties" work that way as well.

When I was new to their corresponding GUI frameworks, the dot + property notation was appealing because it looked clean. However, as I got more experienced I'm no longer seeing the advantage of saving two parentheses characters at the expense of potentially hiding function calls where anything can happen.

I'm not sure why D joined the club given it doesn't have a corresponding de facto GUI framework, and its users even discourage it.

zig and c# each scratch a different itch.

Yes, but that's not a conditional branch, and that's the distinction I've always seen made for flow control versus indirection