In short, I think the answer is yes. It appears that the Win32::OLE Perl package will help you script ArcInfo using Perl.
It's too bad ESRI abandoned their Unix version for a Windows only version. I remember looking into ArcInfo long ago when I was writing software on SGI and Sun boxes for an ocean bottom mapping application using high resolution sonar.
From browsing the ESRI website, it looks like ESRI decided to make their product scriptable by adding a COM interface to ArcInfo, ArcView, and ArcEditor. This means you can script those apps using any programming language that allows you to call COM interfaces. VisualBasic is probably the most commonly used language for COM programming, but you can also use Visual C++, Python, and others.
OLE Automation and Its Relationship to COM
Before Visual Basic 4, you couldn't use VB to directly call a standard COM interface. You could use VB only to call an IDispatch interface, which is a special kind of COM interface. If a COM object implements the IDispatch interface, it is said to provide an OLE Automation interface.
The problem was that you could not use VB (nor most scripting languages) to access C pointers. A raw COM interface is a vtable, an array of pointers to function pointers. The special IDispatch interface provided the information that VB code needed, without requiring access to pointers. I fortunately haven't had to deal with COM and OLE Automation for several years, so some of the details have slipped away from my memory. I think the above is reasonably accurate, though.
Automation interfaces are typically slower, since the IDispatch interface adds an extra layer of indirection.
Microsoft's website has lots of info on .NET here.
Like OLE, ActiveX, and many other Microsoft marketing terms, .NET is a term used to cover a wide range of technologies. To most developers, .NET is the programming model Microsoft would like you to convert to. That is, they would prefer that most developers stop trying to write applications that use low level Win32 and COM calls, since a large numbers of these Windows apps memory like a sieve and crash frequently. And when I say "they", I specifically mean the people working with Microsoft Consulting Services that I have met with.
While some new Microsoft apps will be written on top of .NET, the majority will be written using the low level interfaces. Microsoft created .NET in part to keep IT developers from getting into so much trouble creating buggy apps with the older, difficult to use correctly, programming interfaces.
One thing that .NET provides is a Common Language Runtime. The CLR is very much like a Java Virtual Machine. In fact, much of .NET is modeled on Java and J2EE, except the part of Java that doesn't lock you into the claws of a convicted monopolist. That was a purely Microsoft developed innovation.
COM vs. .NET
So why use .NET if you've got COM interfaces? Well, the .NET runtime manages memory allocation for you (very much like the JVM does). Memory allocation errors are very possibly the greatest cause of unpredictable instability in applications. Memory allocation errors are not only easy to make, but they are often very difficult to debug.
If you are using COM interfaces, you have to deal with reference counting of the interfaces. If you don't keep track of it properly, you'll leak memory all over the place. Microsoft added another technology called ATL (ActiveX Template Library) that made C++ COM programming a little easier, but it's still tough sledding for most programmers.
Also, the .NET interfaces border on sanity and cleanliness. The Win32 interfaces appear to have been designed by 57 independent groups of programmers who disagreed violently on interface conventions. When Microsoft added COM interfaces to many of the Windows subsystems and to apps like Access, Excel, and Word, they cleaned this up a bit. They apparently formed only 43 independent groups of programmers who disagreed violently on interface conventions.