First, Perl under ASP or CGI can access COM objects just fine and is a perfectly acceptable way to put a web front-end on them. If you don't want to use PerlScript in ASP pages, you could try out PerlEx from ActiveState.

Second, Microsoft swears up and down that any idiot can turn their COM objects into web services, so your IS team should be able to do it easilly. Their concerns about performance may be valid though if this application requires very fast response times, since SOAP is not very fast (generate XML, send it over HTTP, parse the XML, generate more, send it back over HTTP, parse again).

But the silliest part of this is that they want you, who volunteered that you "don't know much about object oriented programming and nothing about the .net systems" to learn a new strongly-typed OO language, not to mention the COM model, just so you can put a web interface on their stuff. If they insist on staying with an all-Microsoft stack of products, ASP with VBScript would be a more obvious choice.