We are going to deploy a campus network with approximately 50 switches (Core, Agg, Access). Some of them will be L2 (20), and others will be L3 (30). We are thinking about how to manage these devices:
What would you prefer to use in your network?
As you said, it matters on how many devices we're talking about, but aside from that, what you should avoid if at all possible is only having "in-band" management of your devices. You don't want to have your management traffic riding the same network as your production traffic. If not all of your switches have a separate Ethernet interface for management, that's fine, but nearly every single piece of equipment out there has some form of serial console. USE IT. Especially as a backup for in-band management. This will save your ass if a device falls off of the planet. I'm also suggesting using a completely separate physical infrastructure for management connectivity to your equipment. This applies doubly for serial console access. If you're using one of your interfaces on your switches (that's not a dedicated management interface), that's also not as big of a deal, as long as you've got a separate network to connect it to.
50 devices isn't too unreasonable of a footprint to use a single VLAN (again, assuming you are not doing in-band management) and have one broadcast domain for - you may be trying to optimize too early at this stage. If your core switches are modular boxes then they should most definitely have Ethernet management interfaces - I would advise you to use those rather than an SVI or a physical routed interface.
edit: my personal preferences basically outline what I've advised above: always serial consoles. Use dedicated Ethernet management interfaces where applicable. If dedicated Ethernet management interfaces are not available, then burn a physical port on the box, but always always always a separate network, for serial consoles at the absolute minimum.
This really depends on the network, but I would lean towards the L2 VLAN. While some have expressed concerns about a loop on the VLAN, but in 12 years on big networks, I haven't EVER seen a loop created on a network management VLAN.
Not to say it couldn't happen, but generally people who know enough to set up a management VLAN generally know enough not to be causing loops on the network. Most loops I have come across are on user VLANs where an end user connected/configured something incorrectly or when a server admin misconfigures link aggregation/redundancy on their server or misconfigures a VM environment.
Moving to a L3 approach does avoid that particular problem, but it is also easy to screw up a routed network as well. Yes, you can take precautions, but I stick with KISS when I can and routing is more complex than switching. Shall we start listing the major incidents that have occurred due to routing problems being introduced to the internet?
Ultimately, as John Jensen has pointed out, you should definitely have an OOB management system as well, however I would generally refer to this as a backup to in-band management. Generally speaking I don't recommend changing speed settings on a console port (when it comes to recovery situations, having to figure out if a console port is default, changed or changed incorrectly can be a pain), and even at 115k baud, console ports can be too slow (and many vendors default to 9600 baud).
I would use a separate management VLAN as our colleagues already stated, then traffic vlans as many as required. Furthermore I would be more careful how are you going to interconnect all these switches, what software version run on each device (you have to be sure you run a stable version and most of all do know any reported bug), then plan other things: how do you configure trunks, etherchannels and of course "STP".
