To be honest with you, I'm not even sure where to start with your rant. I'm normally pretty open minded on HN but this is just frustrating to read.
They refused to acknowledge this as a security risk because it's not a security risk. In fact, they specifically call this particular topic out on their Whitehat page under the Ineligible Reports and False Positives heading. They have called attention to this topic as ineligible for a bounty for at least the last two years on that page, because 1) it's not indicative of an application security failure and 2) they receive a vast number of invalid reports about it.
Let's talk about "security through obscurity", a term that has become a hand-wavy way of saying, "I don't really agree with how they're doing this because it seems theoretically imperfect, but I can't really explain why." A series of strings in a URL that are securely generated and infeasible to brute-force do not constitute actual security through obscurity. Security through obscurity is setting SSH to a port other than 22 (and let's be clear - security through obscurity is not a bad thing when it's coupled with best practices). A vast foundation of information security as a discipline relies upon the security of things that are infeasible for a computer to brute-force. Cryptography is a science predicated on the idea that making things extremely work-intensive is an acceptable substitute for information-theoretic security, which is generally unreasonable or redundant in practice.
Each portion of a Facebook CDN image URL is designed with an access and authorization policy in mind. The fbid URL parameter alone is a 64-bit number, and that is only one of the parameters you would need to successfully brute-force in order to correctly identify a valid image URL. How long do you suppose it would take your computer (hell, let's give you 100, each with different IP addresses) to process 9,223,372,036,854,775,807 requests for a particular image URL on the Facebook CDN? But wait, let's not forget, this is not offline cracking - you are making requests to Facebook's servers, where they are free to rate-limit you at the slightest sign of suspicious or abusive activity.
Now let's talk about this model of security at a higher level. Facebook uses a very robust ACL to discriminate between users that are and are not authorized to view a specific resource on facebook.com, before the user can be sent the CDN link. This ACL guarantees that parameters such as the fbid need to be correct before the CDN link will be granted, at which point those parameters are "inherited" by the CDN URL. The CDN uses a capability model, not unlike Imgur's "Private" albums or Google's published, non-public Docs links. If someone has a direct link to the resource, the URL parameters inherent to that link almost certainly suggest that the user is authorized to view it, because it acts as a gate before they could have been redirected to the CDN in the first place. The only other options are 1) a user brute-forced an image URL (good luck!) or 2) someone who was authorized passed the link on to someone who was not authorized.
Seeing that case #2 is the only realistic risk for an image URL compromise, let's continue with that. Is case #2 a problem? From an application security perspective, no, because it doesn't constitute a technical software vulnerability. From a risk assessment perspective, maybe? I agree with Facebook in that if you trust someone with a URL, you implicitly trust them to be prudent in passing that along (at least, in the context of Facebook). But this is a good juncture to talk about risk as a dimension of information security's business process. The context of this discussion is not a military staging server, nor is it even a HIPAA compliant database. This is a CDN for people to store photos on that are inherently designed to be shared with the world. From a risk assessment standpoint, these photos are only designed to be shared with friends. Could your friends do something vindictive with the links? Sure, but in the context of Facebook it's (reasonably!) assumed that you trust your friends enough to not use that access against you. From that perspective, the security measures are optimized for ensuring that only a subset of people (based on the ACL policy) are authorized to view them, not "no one but me." Let's also not forget that even if Facebook designed a much more stringent ACL, your vindictive friends could simply download the image after they are able to view it, and distribute it that way.
Security vulnerabilities do not exist in isolation. They are logical failures between a software's design and implementation, or they are risk failures in a software's design. And even if this presented an issue from a risk assessment perspective, this still does not constitute an application security vulnerability, which means it's not eligible for a bug bounty anyway. In short, you have quite a few bars to pass in order to demonstrate that this is an issue at all.
Finally, I'd like to hear from you what you would do differently. How would you design a CDN for Facebook with a superior security model that matches the same scale and usability requirements?