The main advantage is that if you screw it up or an update borks the shell itself, it's easier to fix if it isn't your login shell. At one point I decided to set Elvish as my login shell, and it turned out to not function as a login shell. As in, won't start at all. Any time I logged in, it would just immediately exit, ending my session. Work doesn't allow us to have root access (annoying), so I ended up having to boot into single user mode to set my shell back. I've done a similar thing with bash and "set -e".
Being new increases the chances of doing something like that that breaks the shell. It's annoying to fix for those of us with experience, and extremely difficult to fix for those without experience. It gets even worse when you consider that some distros like Ubuntu don't set a root password, so you can't log into the root account without sudo, which requires your user to have a functional login shell. I wouldn't want a new user to paint themselves into a corner where the only way to get their desktop working again is to remember how to boot into single user mode or boot from removable media and mount their hard drive. Doubly so if their Linux desktop is their only PC; it's going to be really annoying if the only way to write removable media to boot from is the machine that's currently broken.
Under "Waiting Time". If you're forced to be there, they have to pay you. There have been several cases recently. There was a case against Apple about whether the time spent waiting for them to frisk you counted as payable time, and I believe another against Amazon relating to how long it took to get into their parking lot. I don't recall offhand what the decisions were, but they're easy to find if you're interested.
I would avoid it for most roles. And not just India, but really anywhere that's more than a 6 hour time difference from where I work (and even then, I would prefer less than a 4 hour time difference).
I work on a globally distributed team currently. It is exceptionally difficult to maintain cohesiveness as a team given that there are 0 hours per day that we are all online. What has ended up happening is that we have virtually fragmented into 3 separate teams with our own products. For instance, my team members in Asia are working on a product that I can't effectively support because my shift doesn't overlap. If someone asks me a question about that app, which my team is supposed to support, I have to go start reading source code. Lacking documentation is also an issue there, but that's nearly a universal problem.
Remote working tools are the hot new thing, but nothing effectively solves the timezone issue. Sure, we have async communication, but unless someone is logging in after hours (which I would heavily discourage), you only get one exchange (i.e. an email or Slack message) per day. That's a painfully slow way to collaborate.
That being said, there are roles where the time difference doesn't matter, and is advantageous. NOC and helpdesk (if helpdesk is 24 hours) are well suited to a "follow the sun" model. The team communication seems largely limited to passing off info about incidents, with very occasional full group meetings to give new policy info. They just aren't the prestigious roles typically associated with SV.
I would argue that becoming "legacy" is akin to bit rot. Sure, it still runs, but everyone that knew how it worked has left the company, and it's written in a language that is no longer in vogue and will require specifically hiring people with that skill to maintain.
As a counterpoint, I think we can both agree that writing production software in one of the toy languages that pops up on HN frontpage every day is a bad idea. Writing in a language that is old enough that it has become niche has many of the same issues. It doesn't really matter whether the software is poorly understood because the language is new enough to be niche or old enough to be niche; the outcome is the same.
Why? The situation in which it occurs is unambiguous. Allocate more memory than is available and watch it fail less than gracefully. What you're suggesting is merely technical gatekeeping; there is nothing to gain from writing a special purpose OOM-causer, no less specifying that it must be written in C.