Hello @okram, welcome.
If you have interest and knowledge in type systems in "Lisp-inspired" languages, that would be valuable if you care to offer specific feedback...
...but we're a pretty long way from dependent types. :-/ Also...the language is interpreted, not compiled. We're not particularly focused on performance, more expressivity. (Catchphrase: "Minecraft of Programming")
While there are a bunch of interesting and nuanced details in the language to talk about, the "type system" barely exists. There's around 64 basic value types (word, set-word:, pa/th, {string}, #token, 304, $10.20, [bl 0 ck], (gr 0 up)...), plus arbitrary quoting levels ('''['a ''2 ''(a 'b ''c)]), and a NULL non-value.
Historical Rebol takes for granted that you can reflect the type of things. We now do that via REFLECT:
>> reflect [a b c] 'type
== block ; (the representation of this answer is what's up for debate)
A version of REFLECT which quotes its left hand side is available as OF, which is neat:
>> type of [a b c]
== block
But the question we're stuck with is that answer. It has been assumed that whatever you get back, it would be suitable for plain equality comparison with...checked against the answer you got for something else. It doesn't seem that Lisp goes with that idea of a kind of "canon answer", and pushes you to use a function to check for type matching.
In terms of our type representation...we're reluctant to re-use an existing type (such as WORD, which is what the symbol block would be). The reason is that we'd like "datatype's type" to be able to stand on its own, such as when matching things against rules:
>> parse [4 5 6] [some @integer] then [print "Matched some integers!"]
Matched some integers!
We'd have to invent special keywords or signals otherwise:
parse [4 5 6] [some typep 'integer] then [print "Not as nice"]
Using the @symbol category for types wouldn't mean it couldn't be used for other purposes, but it would make many dialects want to save it for when types were relevant.
But there are other questions, like is the type of all quoted things @quoted?
>> type of first ['''a]
== @quoted
>> type of first [''1]
== @quoted
Or do the types themselves come back as quoted?
>> type of first ['''a]
== '''@word
>> type of first [''1]
== ''@integer
Or...since the evaluator drops quoting levels, is it better to insulate the quotes by putting them inside an inert container like a block:
>> type of first ['''a]
== @['''word]
>> type of first [''1]
== @[''integer]
There are much deeper questions to get at with user-defined types, and how they might interoperate with generics...all of which are unknowns.
Given the vast underdevelopment in such areas, 
it takes something of a commitment to learning why the medium would be interesting! But always open to explaining that. 