There are two possible consumers of version numbers. Your internal processes and people using your service.
With internal processes, version numbers help you identify when something was fixed and what has changed since them. By saying "we fixed this in version 1.2.3" you know where that was done and if you are now experiencing the same bug, you've got a regression. By being able to identify when it was fixed or implemented (with a version number) you can now narrow down what you need to do to fix it.
Consumers of the service can also use version numbers. Not all consumers need to know version numbers, but it is something that can help them. By saying "these bugs were fixed in version 1.2.3 which was deployed on some date" you, as the consumer know that bugs that you may have reported are fixed. Furthermore, when reporting bugs you have the opportunity to say "this was fixed in 1.2.3 but now in 1.2.5 it is broken again." This is possibly valuable information for reporting bugs.
Many times, software as a service also has an API for interfacing to it. This API should be also versioned. You can see this with the Stack Exchange API and Google's data APIs. An API is very much like a library which is hosted on another server. Just as libraries are versioned, so are APIs.
The purpose of a version number in these cases is to allow more efficient communication of the information about what software something was reported in, fixed in, and currently running. That there is only one instance of the 'currently running' doesn't lessen the usefulness of the first two points. It is useful for internal and external alike.
Consider also that unless you are offering an API, semantic versioning is not necessarily as useful. I've worked in situations where the build number from the continuous integration server was sufficiently useful for a version number - "production is running build 123, we fixed that in build 145 which is currently being tested in the QA environment. The current build is 155."