Continuous integration as a term refers to two distinct ideas.
The first is a workflow: instead of everyone in a team working on their own branch and then after a couple of weeks of programming try to merge their changes into the mainline, that changes are integrated (nearly) continuously. This allows problems to surface early, and avoids incompatible changes. However, that requires that we can easily check whether a change “works”.
This is where the second idea comes in, which turned out much more popular. A CI server is a clean environment where the changes are tested as quickly as possible. The clean environment is necessary so that the build is reproducible. If it works once, it should always work. This avoids “but it worked on my machine” problems. In particular, a CI server is valuable when your software runs on different systems or in different configurations and you need to be sure everything works.
The lack of a build step is irrelevant. However, CI only makes sense if you have a test suite. This test suite must be automatic, and must have no failures. If the tests fail, the appropriate developer should get a notification so that they can fix the problem they introduced (“breaking the build”, even when there is no build as compilation).
It turns out that such a server is valuable for more than just testing. In fact, most CI software is really crappy at running tests in various configurations, but good at managing all kinds of jobs. E.g. in addition to “continuous” unit tests, there could be a full test as a nightly build. The software can be tested with multiple Python versions, different library versions. A web site could be tested for dead links. We can run static analysis, style checkers, test coverage tools, etc. over the code. Documentation can be generated. When all test suites pass, the packaging process could be initiated so that you would be ready to release your software. This is useful in an agile setting where you want a deployable (and demoable) product at all times. With the rise of web apps, there's also the idea of continuous deployment: If all tests pass, we can automatically push the changes to production. Of course, this requires that you are really confident in your test suite (if not, you have bigger problems).