The cost is one of the reasons.
When you're implementing a feature which is used by half of your 1 000 000 users, it means that the cost of the feature is divided by 500 000. Even if implementing it is terribly expensive, it doesn't matter. If this feature costs you $100 000, each user will pay ten cents, given that only half of the users will pay for the feature they don't use.
When, on the other hand, a feature is used only by a few of your users, not only it doesn't worth to implement it, but often, you will even stop supporting an existent one and remove it from the product. This is what happens often in Microsoft products: when you read that a feature, used by thousands of users, was discontinued in the next version of Windows, it is easy to understand: maintaining a codebase used by only a few thousands of users is too expensive for a product with so many customers.
The same applies to bugs. If 1% of your users are encountering a bug, it may be too expensive to solve it. The less costly way would be to refund those users, and never hear from them again.
The second reason is that it is difficult to find the edge cases.
An example. I was recently working on a standardization of username/password authentication for my company.
One way was to do it in the same way as it is done by Microsoft, PayPal and others: the bad way. In other words, you don't really care about the edge cases, and try to circumvent them by having passwords with the maximum length of 16 characters, etc.
Those companies know that most users will use a password such as "horse123", and will never experience any problem. On the other hand, I with my 25-characters randomly generated passwords, can't access my Microsoft account from Windows 8 Metro apps done by Microsoft itself, and I can't access my PayPal account, unless I manually tweak the password to be actually different from the one I used when registering.
But they really don't care, because I'm different from 99.9% of users.
The other way is to try to find all the edge cases. For example, if you want to support any unicode character in a password, you should know that some characters may have multiple unicode representations, and while the user will believe that he enters the same password, your app will reply that the password is sometimes right, sometimes wrong, depending on the unicode form. In the same way, some characters should be forbidden: if the system allows \u0014, for example, bad things will happen (like Internet Explorer 10 hanging for 30 seconds when submitting a form with a password containing such characters).
In general, it comes to what is more convenient to do business-wise.
You can spend the next few months searching for edge cases,
or you can implement three or four cool features in your product.
Ask your boss what should you do among those two options.
