The benefit can range from negative to positive for your enterprise. Much depends on how such capabilities will assist your enterprise vs. the cost of using those capabilities.
Usually, and unsurprisingly, networking groups know little about software development and its ongoing "care and feeding". I.e. they often miscalculate the value, to the enterprise, for creating their own software based solutions and also miscalculate the initial and ongoing costs to maintain such internal software.
@bigevilbeard's reply presents a couple of excellent examples of using internally developed software, but even ignoring the cost of his time developing that software, what happens if he leaves, especially if the networking devices "change" requiring modifications to the software he developed?
Don't misunderstand, I'm not saying what he described as having been a bad thing to have done, but neither am I saying it was a good thing, insufficient information to say.
BTW, for the record, in modern parlance, I'm a software engineer who often pretends to be a network engineer. ; )
A fine example of benefiting from internal programming, while at one company, with about 5,000 network devices, most being L3 running OSPF, we were given the directive to change all their area attributes; a huge manual change and with possibly a long time with parts of the network being disruptive.
Actually, we used two different approaches, on different sections of the network, the night of the big change.
One group, basically, updated L3 startup configs with the revised area attributes and scheduled all revised devices to reboot at the same time.
In my case, I wrote a Python script to walk the OSPF tree, from core, using each device's internal telnet to connect to downstream peers and applied changes, dynamically, from "leaves" working back to core.
Since this was, in theory, a one time change, ongoing support of my Python script wasn't an issue.
Both approaches accomplished their conversions. Which was "better", hard to say. Overall, believe more man hours were invested in the manual configuration changes. In theory, the manual conversion's execution took less time, but in actual execution, some (few) devices didn't come back on-line when they rebooted, and it took time to resolve them. So, overall change execution time, as an average, was about the same.
I'll also say, it's nice to have this skill set on-hand, so you can do automation you otherwise could not do, but conversely, the fact you can do something, doesn't imply you should do something.
Then there are a couple of "touchy" people issues to consider to. First, the possible cost to provide such training. The possible additional cost to retain your newly trained engineers, as they're now more market valuable. The chance in losing such engineers because they are unable to use their new skills.
