It is like merging because it is merging. Consider by way of example:
A <- B <- C
\
\<-D
Suppose you ask to rebase D on top of C. Git asks itself what is the difference between B and D: what would you have to do to B in order to get to D? It then "replays" that difference onto C: that is, it tries to generate a new commit that does that same thing with respect to B, but is attached to C.
Well, depending on what C did to B, it may not be obvious how to do that. A change made by C with respect to B can be "in the way" of making a change to B. If C changed line 1 of a file in B to "hello" and D changed line 1 of the "same" file in B to "goodbye", what now should this new commit do in relation to C?
If you think the answer is obvious — that is, if you think B or D is "right" in this regard — then just resolve the conflict. Conflicts are not bad! They just answer questions where git fears that its answer might go against your wishes.