There are a few different reasons you might want an SRD.
First, it's a handy core of resources that you can use when developing your game.
It also serves this role for others, which is nice if you want to have your game serve as the foundation for an ecosystem of games.
When you make an openly licensed game, using an SRD allows you to delineate your free and open content from content which you wish to keep proprietary.
It can also be a play aid, a streamlined version of what you have in a rulebook.
The internal system reference document is one which is used by you as a developer and may or may not be publicly available. The intent is to let you work on a core for your game which can then be applied to other games.
The uses of an internal system reference document include the obvious use as a reference material (which can be faster than searching a fully developed game for rules), but go further.
It is generally unwise to include more than one variant of rules in a game. I will do this when there is a "quick" and a "full" way to play, but that's the absolute limit.
However, this doesn't mean that a ruleset will be universal. You may specialize rules for combat in a fantasy setting, where engagement ranges are short, and then work out rules for combat in a futuristic setting where the only limit on effective weapon ranges is line of sight.
An SRD can host both of these simultaneously precisely because it isn't intended for play. You can have the rules that fit best integrated into the games you release on a per-case basis instead of having them combined in one thing.
With a tabletop roleplaying game, you have player-facing content and GM-facing content, with developer-facing content being something that you might include if you want to give individual GMs more control over tailoring their experience.
When it's something like the rules for creating more content, this may be desirable, but if you have notes on design decisions and mathematical background information it may be better to dive into those in the SRD, where you can have them to your heart's content.
In an age of primarily digital distribution, length restrictions seem less important, but prospective customers still want to have an experience they can play. Just like a customer might have sticker-shock from an expensive product, they can have length-shock from an oversized game.
Distributing 500-page digital books has added overhead even if it's less expensive than handling massive doorstoppers, since an SRD just has to be legible but a customer-facing product should be refined.
If you are working with a team, having a core foundation that they can look at in the SRD is a way to help on-board new arrivals and get them up to speed. While they should probably come to terms with the entire content, especially if they're doing significant work with the game, you have to start somewhere and an SRD is more approachable than a full game manuscript.
Again, setting aside the reference material uses, let's look at what other designers might use your system reference document for.
As mentioned in more detail in our post specifically about licensing, an SRD is a great way to officially clear lots of content for use under a permissive license, but it can also be useful to separate rules you are fine with public distribution of from proprietary content that you want to keep confidential or more tightly controlled.
Because an SRD is only part of a product, even if it is a full-blown playable game in its own right, you can exclude anything that isn't neatly licensed under your license of choice from an SRD and distribute it to people evaluating or using your system for their own games.
An SRD is easier to work with than a whole game, and just because you make a whole game free and publicly accessible doesn't mean that it will work for other designers.
By creating a separate document that has just the parts that a designer is interested in, you make it a lot easier for people to check out stuff and work from it, instead of having to deal with the same customer-facing product that you made with your core rules or a home-modified version to strip out content they don't care about.
There is a market specifically for SRDs that doesn't exist for games. If I tell another designer to check out a game, even if its license would permit its use in the same way an SRD would, they aren't going to have the same response as they would with an SRD.
That's not to say that SRDs always have a great reputation, but if your SRD is publicly available on a platform like itch.io you can also get much more traffic from people looking for an SRD. It's a win-win situation, and lets you essentially publish twice from the same content and get two different audiences looking at it. Since SRDs require less polish and detail than a standard product (though they should still be presentable, both for your own sake and for those using the SRD), this is a low-investment way to market a game.
Customers–players and GMs–also benefit from having access to your SRD.
If your rulebook is expensive or print-exclusive, it can be a deterrence from piracy, since the players can use a legitimate copy for the main play experience and an SRD for referencing rules and basic stuff (this is more likely to work if your SRD contains a generous portion of content, but it still helps even if it doesn't).
It also presents a try before you buy option, since an SRD contains more of a sample than many marketplace listings will without necessarily shutting down players' interest in buying your product. If you go for the gated content strategy, where a lot of content is in your rulebooks and the SRD contains either generic or partial replicas of the rulebook content, the SRD can serve as a taste for what players should expect from the game as a whole.
System reference document uses go far beyond mere reference. The exact benefits depend on the type of SRD, how it is licensed, and which users' perspective you are evaluating.
As with anything, there's a cost and a benefit to an SRD, but it opens up a lot of pathways for professional designers that might not be available with a traditional product-line focused approach.
Check out the following articles for more information on SRDs:
The Art of the System Reference Document: Licensing
The Art of the System Reference Document: Types
