Because if the app is storing your data, it's responsible for keeping it secret. To take an example, let's say there's an app to store something you'd rather keep quiet, such as your collection of Jason Donovan albums. This app would have a database with the relevant information inside, and this database is private to the app. No other app can read it (without root), and thus your embarrassing music taste is kept secret.
Now let's say the app author wants to allow other apps to use the same data. It could be another app by the same author, or he could widen it to allow other authors to access the data. That way, other apps would be able to add a home screen widget with a Jason Donovan album of the day, or create calendar entries for the anniversary of each album's release, or import anything else. He does this by creating a content provider, adding it to the manifest, and publishing instructions for developers on the format of the data and how to access them. The content provider is like a server: it provides a way for other apps to query the app's data and get results back, without accessing the database directly.
If that's all he does, then any installed app can access the data. You install an innocuous-looking flashlight app that only has "INTERNET" permission, and suddenly it's able to find out all your embarrassing music and email it to scammers for blackmail purposes. Obviously this is undesirable: an app developer who would let this happen should not be trusted with your data.
The app developer can prevent this by creating a new permission, and giving it a human-readable description, such as "Read your favourite Jason Donovan albums". Creating the permission doesn't do anything itself: he also needs to change the content provider so that when an app queries it, it checks that that app has the permission before responding to the request. If the app has the permission, it gives it the data it asked for; if the app doesn't, it might choose to give it an exception (an error that tells the program what the problem is), or simply to return no or partial results. For example, it might tell the app about the Rolling Stones albums you're not ashamed about, but not the embarrassing Jason Donovan albums.
This way, the innocuous-looking flashlight app can't access your data. Before you install an app that wants access to the data, you can see "Read your favourite Jason Donovan albums" in the list of permissions, and you can abort installing if you don't trust the app author with that information.
How many permissions the app creates depends on what kind of access it offers other apps, and how fine-grained the controls should be. In our example, the app doesn't have a way for other apps to add albums, so there's no need for a read-write permission. Even if it did, it may be that the app only has a read-write permission, which other apps need to have to either see the list of albums or edit the list. This might be enough for a simple app like this. But for something like a social media app, it's more important to limit how many apps can send messages (or write content) on your behalf, so two separate permissions might be used in that case. It's up to the app author to decide how many permissions are appropriate for the app, giving users control over their privacy without creating confusing combinations that are hard to understand.