A lot of it is historical. What rkt added conceptually when it was introduced was 1) a spec and test suite, 2) signed/content-addressable images and first class third party repos, 3) not running everything under a single daemon.

Since then, Docker has improved quite a bit on these so the most in your face practical differences are smaller, but there are still philosophical differences that affects it.

E.g. rkt comes out of CoreOS. CoreOS does a lot around embracing systemd to its full extent. Systemd can provide a lot of the capabilities that Docker did itself, and parts of rkt's design flows from that. E.g. restarting, querying status, capturing the logs, so in a systemd based system, Docker integrated fairly poorly in that systemd would be starting and keeping track of a Docker client rather than the process actually controlling the container, while rkt fits right in.

Again, the difference is getting smaller, and various tools like runc etc. from Docker now allows you narrow the gap even more (if you put in extra effort).

Try both, basically - they're similar enough that it's worth figuring out which "flavor" you like best.