The artifact repository has several goals. The main goal is to have a copy of the maven center (or any other maven repo) in order to have faster download times, and you can use maven even if the internet is down. Since you are not using maven, this is not relevant to you.
The second goal is to store the files that you want to use as a dependency, but you cannot freely download them from the Internet. So you buy them or get them from your suppliers and put them in your repo. This is also more applicable to the maven user and the dependency mechanism.
The third important goal is to have a central path so that you can keep your releases. Therefore, if you create version v1.0, you can download it to such a repository and with a clean naming method in maven it is easy to learn how to find v1.0 and use it with all other tools. That way you can write a script that downloads your release using wget and installs it on the host.
In most cases, these repositories have an intermediate process method. Thus, you can store v1.0 in the repo at the stage of setting. Someone is doing a test, and when his fine is pushing him to a repo release, everyone can find and use it.
Its easy integration with Maven projects, and they have many other build tool frameworks that are easy to connect with, such as ant ivy, groovy grape, etc. Due to the naming scheme, there are no restrictions that you use bash or perl to load / unload files from it.
So, if you have releases or files that need to be shared between projects and they don’t have a good solution, the artefact repository could be a good starting point to see how this might work.