Assuming that the underlying cloud providers are secure (meaning that they don't leak information from the IDs, or grant unauthorized access to change the project settings that they refer to), there's generally no real problem with the IDs being committed. They disclose the fact that a service relationship exists, nothing more. Of course, the rest of the code that interfaces via those IDs would also disclose that the relationship exists.
However, committing the logging email addresses is an issue. If those email addresses are leaked, and there's enough information committed around them to reconstruct the form of the logs, it increases the risk of processing if the sender of the logs doesn't properly sign them with DKIM or such, and/or if the recipient doesn't verify that signature before acting on them. Note that you can't really trust email logs without verifying them, regardless; because email addresses are also subject to receiving unsolicited and unwanted messages, you could end up processing some email of an improper form if you're not careful. The probability of having to deal with such also goes up when you commit the email address into a public repository. (If you want to test your ability to properly handle undesired submissions to that email address, by all means. But you could also test that by sending to that email address from unapproved submission email addresses as well.)
As always, the ultimate decision to do such should be firmly rooted in your security policy, which is necessarily based on your threat assessments and mitigation strategies for those threats. Anybody here can only express their thoughts based on their own understandings of the issues involved, and nobody here has any idea what your threat mitigation strategies are -- or even what they should be based on information that only you have. Make wise decisions, which almost certainly don't include "accepting and acting on the word of random StackExchange members with no additional critical thought".
