Sometimes the production of an artifact is the focal point of a process. Other times, artifacts are a byproduct of the process or they're not created at all. In some cases, it's simply a matter of perspective. For example, is a piece of working code an artifact, a change in product state, or the meeting of a requirement or goal? Pick any three. :)
While one can certainly point to processes that are arguably free of artifacts or milestones, it's a somewhat definitional exercise. The real point of the text you quoted is to communicate that a process need not produce a concrete deliverable to be considered a process.
In an agile context, user stories can represent state changes within the iterative development process. A user story generally changes state in several ways:
A user story conceptually moves from one queue or column to another. For example:
a story may be handed off between development and QA, or
a feature may be merged into the continuous integration branch.
While there may be tangible outputs involved, the tracking process itself has state-change as its primary output.
A user story changes its status from not done -> done, or incomplete -> complete according to the Definition of Done. This is about as pure an example of state change as you are likely to find.
In other words, while a process may produce an artifact (e.g. a document, a demo at a Sprint Review, or a user-visible feature within the product), it doesn't have to produce an artifact to be considered a process. A process may deliver something tangible like a new widget, change the state of something by updating a document or embiggening a whatsit, or it may simply output something intangible like an idea as input to another process.