There are several rational arguments for this.
First rational argument: Businesses, that want to make money (i.e. stay in business), want something in exchange for access to their services on the Internet. An e-mail address is a perfectly good mechanism of trade. Let’s pretend I’m a business owner: You give me your e-mail address, I give you access to my service because I, as the business owner, deem that a valid form of trade. Businesses will take either that or money - a credit card, PayPal transfer, etc. Which would you rather do - pay money or give your e-mail address? Nothing is free but you sound like the sort of person that wants everything for free because you don’t associate value to services. Go start a business and you’ll change your perspective REALLY fast.
Another rational argument: If we have to ask for the e-mail address, we also have to VERIFY it. This is the step that sign in authentication with a trusted service has already done. If you sign in with Twitter, Google, Facebook, etc. you’ve already validated the e-mail address with them. The verification step in any software product is a painful process that is difficult to implement correctly and users hate doing verification. Therefore, verifying after signing in with Twitter defeats the entire purpose of signing in with Twitter.
Final rational argument: A shared e-mail address across multiple sign in services is quite compelling for improving end-user usability. A user could have (and a lot of people do) the same e-mail address associated with Twitter, Google, Facebook, and other sites. Are they going to remember which social media service they signed in with on all websites or that they’ve been to your website before? No. Should the sign in portion of the software care? Probably not. However, an e-mail address from a sign in provider is quite useful for automatically linking accounts that would otherwise not be linked.
Also, arguments against a feature in an API are moot when it goes against an overwhelming desire for the feature. This thread is clamoring for it and you and a Twitter dev are the only two against it. While you are fine with and free to not use e-mail addresses in your web applications, it is plainly obvious to me that everyone else wants it and I will operate under the assumption that the reasons are legitimate until proven otherwise. Your arguments against this imply that programmers don’t know what they are doing - thedailywtf.com exists toward that end as well. But there are still plenty of decent to great programmers out there that do know what they are doing and one or more of my arguments above apply to them and they see Twitter as useless and are rightly justified in thinking so.
Now, I will agree with you on one point: If a service wants an e-mail address or ANY other piece of information (first and last name, birthday, username, etc.), it is VERY important to display why that information is desired and precisely what purposes the information will be used for. These things are traditionally accomplished via “Terms of Service” and “Privacy Policy” statements. I’d love to be able to pass URLs to the various sign in services out there and have links show up that point to documents on my site that describe, in detail, what each piece of information is used for BEFORE the user agrees to sign in. It becomes weird to agree to a ToS and Privacy Policy statement AFTER you’ve already signed in and, in addition, waters down legal standing in a court of law. Given this day and age of lawsuit happy lawyers, I see the lack of such a feature as a major downside to the various sign in services. Having this feature would address your issues with asking for your e-mail address and not knowing what it will be used for while simultaneously appeasing the life-sucking lawyers of this world.
Ultimately, I still stand by my original statements. If Twitter wants to stay relevant, it needs to move forward now on this feature.