The messages passed thru Biztalk are a serializable .Net class that contain a message context (dictionary of name/value pairs) and a stream of bytes.
In an orchestration you can receive a message of type XmlDocument. This does not mean the message has to be Xml. It means there is no MessageType on the messagebox subscription, so it will accept any type of message, even an image file. You will still have access to all the message context properties promoted by the adapter and pipeline components, including the FILE.ReceivedFileName if the message came from a file adapter.
So your mechanism of sending an Xml file with the file name, which then uses a .Net component to read the file is not needed. You can simply have a single receive location with a file mask of *.* , a pass-thru pipeline and an orchestration accepting untyped messages, you will have achieved the same result.
You could still use other receive locations on this receive port to accept xml files for example. Have a single receive location with the XmlReceive pipeline, which would determine the message type for you. In the orchestration you could check to see if BTS.MessageType property is set this would save you calling a receive pipeline first. Otherwise you can use your custom logic inside your orchestration to determine the pipeline to call to process the input file, perform some logic and and call the output pipeline and send the output. You still need to have a lot of configuration, that will enable you to determine which pipelines to call.
Personally I would use as much of the functionality in the product as possible. The configuration setup is a one-off task that will probably be less effort than writing, testing and maintaining your own version of message routing.