Wikipedia has a very good answer to this question. Artifact, sometimes also called Derived Object, is a product of some process applied to the Code Repository. Originally they were called Build Artifacts, but as more processes were applied other than build to create them, the first word was simply dropped.
The major distinction is that artifacts can be recreated from the code repository using the same process, providing you have preserved the environment in which the process was applied. As this process can be time consuming and the environment can be preserved imperfectly to be able to recreate the artifacts in the exact same way, we started to store them in Artifact Repositories.
Storing them apart from Code Repository in an Artifact Repository is a design decision a DevOps engineer would make. Some companies, namely Perforce, suggest to use their Code Repository as Artifact Repository as well. There are different requirements in terms of access, auditing, object sizes, object tagging and scalability on each repository and so depending on situation it is often better to use two distinct products. For example Git repositories are copied in their entirety to every development machine and so storing artifacts in the code repository would increase its size beyond all reason, although lately there are ways to mitigate this. Another decision to make is which artifacts to store. Some companies store even intermediate artifacts as individual object files, to speed re-builds, others store simply just the final binaries. Not all artifacts have the same value. Artifacts resulting from a release build could have different requirements than artifacts resulting from a developer build.
Most common artifacts are results of the following processes: Configuration, Preprocessing, Compilation, Linking, Automated Testing, Archiving, Packaging, Media files creation and processing, Data File Generation, Documentation Parsing, Code analyzing, QA, etc.