Brad mentions there's no limitations on entry types, though whether it's a good idea long term for maintainability and UI purposes is another story.
Entry Types are the most useful when your content is quite different among them but you still want to keep entries together in the same section.
For example, in a News section, you might have a
Link to Page entry type where you link off to different websites and a
Blog Entry type where they're just regular entries. (John Gruber's Daring Fireball site is a good example of this.
In my experience, when a user starts to see a dozen or so entry types, it can start to become pretty overwhelming... here's what 50 of them staring you in the face might look like:
Entry types are useful because they each have their own set of fields.
However, from a maintainability standpoint, let's say you want to add or move a field in every report. Doing it to 2 or 3 entry types is pretty straightforward but doing it consistently to 50? Way harder—whether you're using YAML files or the GUI!
The 80/20 rule might be helpful here: I'm guessing 80% of the reports generated are probably going to fall into 20% of their types. That just narrowed down the number of entry types to 10. Maybe you add a few other more common ones plus a catch-all "Other..." entry type or something.
Unless your client is also a fellow developer/designer, they don't want to be adding fields and sections to the backend unless absolutely necessary.
If I were you, I might ask you client: what's different about each report? What's the same? You'll come across some good answers which can help you and your client model this nicely.
That could lead you to use something like Categories instead, where it's very easy to add new ones. If the report types are more like filters, they also will show much nicer in the GUI.
And maybe you do need some report types to hide and show different fields but are otherwise pretty similar. You might consider doing this with, say, the Reasons plugin.
Food for thought!