Just to expand on the parent's point further: it's not just about what the service does, it's about what could happen in a worst-case scenario if the service is compromised by an attacker.
Companies get hacked. Well-known companies get breached and their data stolen. When these companies store access credentials from users, those access credentials can be stolen too. For example, see the recent DataDog breach [1]. Security credentials that customers gave to DataDog, for the purpose of allowing DataDog to monitor their infrastructure, were compromied by an attacker:
> the attacker gained unauthorized access to three of our AWS EC2 instances and a subset of our AWS S3 buckets. Those AWS resources included user credentials for the Datadog service, service metadata, and credentials shared with Datadog for third-party integrations.
The attacker then used those credentials to penetrate systems owned by those customers! Customers were hacked not because the customer did anything wrong, but because they trusted DataDog, and DataDog did something wrong.
Security-conscious customers will consider the implications of trusting any service they rely upon, and will consider "What could go wrong?". Very few companies get security right enough to avoid being breached.
A company with read/write access to many users' GitHub repositories, including private repositories, will certainly be a major target for attackers. It's not so much that attackers care about source code per se. Rather, attackers know that all kinds of other information such as access credentials, username/passwords, etc. get checked into source control by accident or sometimes even intentionally. The credentials might be hidden in the sense that they don't show up in a branch currently, but are present in some historical version of some branch - perhaps a dotfile someone checked in by mistake, and deleted, but didn't erase the history of. It happens. An attacker will scan this source history and find those credentials.
Every company that accepts credentials from customers to integrate with other parties should understand the pivotal role they play in the security of their customers. What the service intends to do is only part of the story. What the service could do if compromised by an attacker is an important piece of the story, and limiting this blast radius by embracing least privilege is an important part of earning the trust of security-conscious customers.
It is a shame that GitHub does not make least privilege possible in this scenario, by failing to offer a form of access less powerful than read/write access. To solve this problem well, GitHub would ideally offer a read-only API, and perhaps a read-only metadata API that can view commit histories but not the content of commits. Then, a service integration built on this API can reassure its customers that, even if the service is hacked, an attacker has no ability to push commits to customer repos, nor view customer source code.
[1] https://www.datadoghq.com/blog/2016-07-08-security-notice/