How many players does Unity's built-in networking support?

Short answer: It very much depends on a lot of variables. There is no short answer to this - unless you provide an amazing amount of details in your question.

Longer answer:

In general, for most or all types of games - unless you're making major mistakes during design / development, up to around 20 players should be quite safe.

Obviously, if you're spamming hundreds of RPCs (remote procedure calls) with lots of data in their parameters every frame, you and your players will be in trouble - if you do it "just right" (um, wrong) even 10 players might be too much. But honestly, if you do that, you should simply not be creating multiplayer games (try DDoS-attack-viruses instead ;-) ).

If you're very careful to make your game design "network-efficient", you can probably create an action-based multiplayer game based on Unity networking with a few more players. I think 50, maybe 100 should be doable unless everyone sees everyone all the time. Think about it this this way: If you have 100 players, and everyone sees everyone (which means everyone needs everyone's updates), adding 1 player (101) will add the need for 100 players getting updates from that one player; and 1 player extra getting updates from 100 players. You certainly want to avoid that kind of quadratic growth of need for resources (bandwidth, computing power etc.)

Another thing I've noticed: A single player with a "bad machine" can pull down you're networking quite a bit if you're not careful, so you might add checks and timeouts to prevent such cases (again: depends a lot on your game design, in particular on how much dependencies you create between players).

Whatever you do, do a lot of testing and start testing as early as possible. In fact, it may be a very good idea to build testing in right from the first steps. The later you start, the harder integrating testing becomes (obviously depends very much on your game design again: some game designs make it very easy to set up testing environments, others make it very hard).

And be aware, that your tests really only say something about the number of players you've tested with (and simulated AI players might behave very differently from actual human players). Adding only a few percent more players might turn the game from "nicely playable" to "lag-fest". If your game does some smart filtering (everyone only gets the relevant updates, and not so much is relevant), think about the worst case scenario: Everything might be just fine when everyone's evenly distributed across the map(s) - but when the players decide to test your server (which sometimes, players do intentionally - just to see if you made your homework), and all run to the same spot ... guess how much your smart filtering will help in that situation.

So the key is: Proper game design. That kind of "worst case" can be made impossible if you design your game in a way that will make it impossible for players to do such things (e.g. have rooms and each room only accepts a maximum number of players ... if more players want to enter ... well, tell them "door is closed, party's full, you're not welcome ATM"). But don't think it's easy to do that without giving the players a feeling of "feeling limited" (be polite - my example was meant to be funny).

Speaking of game design: Your game might be a turn-based game, only requiring a few messages per player every few seconds. You could still use Unity networking for that (RPCs). You could also use a Website the game talks to for that kind of game. But whatever you use: A simple, well-designed turn-based game can probably take hundreds or even thousands of players with Unity's networking ... at least as each "turn" doesn't require massive amounts of computation. In that case, you're back down to "just a few players" again.

So in the end, it comes down to: What kind of game are you going to develop, and how capable are you of a) designing the game "networking-friendly" and b) implementing your "networking-friendly game design" in a way that really is networking-friendly.

It's certainly not easy - but it can be a lot of fun!