Are on-call rotations for software developers commonplace or unusual?
There is a very wide range based on country, industry and type of development job.
Generally speaking, if your software is running during off-hours and needs to service customers (that may or may not be humans) during off-hours, then having people on stand-by to fix upcoming issues is indeed normal.
Whether that is the actual developers of the software depends on the size of the company. The larger the company, the higher the chance they have an "operations" department set apart from the "development" department.
Being on-call should be a regulated activity, that has shifts, responsibilities, is paid and is compliant with all the regulations there are.
In smaller (or less organized or just cheap) companies, "on call" might just mean someone has the developers private number and will bother them if the software isn't servicing customers any more. However, there is no expectation that the developer is actually reachable and able to work at any time. They might be 3 hours out totally drunk on a friends wedding. They aren't on-call. They just were called.
Please note that having an on-call is definetly neccessary, not matter how good of a job the developers do. It's like an ambulance or fire department. You don't dissolve them because there hasn't been a fire recently. They are the safety net.
In good companies, being on-call is a no brainer. A money maker. You are sitting there playing a computer game all evening and you are making money for it, too. You basically sold your right to go out and party, get drunk or otherwise inhibited and drive to far away places. Something you may not have done anyway. In my former team, we always had enough volunteers for on-call that I did not have to do it all year, even if we all signed the same contract. They wanted to do it. Because they knew we did such a good job, it was highly unlikely they would ever get a call.
However, in bad companies or bad teams, on-call can be nerve wrecking. Constantly putting out fires on your supposedly free evening. Never knowing when you will get the call and who will breathe down your neck. Not knowing where in your bugg ridden product it broke this time.
So to sum that up: being on-call is very common in industries where the product is running and covered by SLAs or customer facing. Whether on-call is an easy time or a nightmare is up to the producers of the software. That means developers and their direct project environment. Produce quality and you will have to watch over a quality product, a great job to have. Build a shitty bug ridden product and you have to watch a clown on fire stumbling through a hornets nest. Sure, you will come off as the hero, but only to people who don't ask what the hell the clown was doing there in the first place, why it was on fire and how there happened to be a hornets nest.
In countries with labor laws to speak off, on-call is highly regulated. In others, it's not.