The border between a fundamental type and an object is blurred and often artificially introduced. For example, In C a struct is just a bunch of records, just a derived non-object type. In C++, a struct is a class with all fields public, an object. Still, C++ is almost totally backwards compatible with C... the border is really soft here.
For prototype-based programming you need to have objects mutable at runtime. They MUST be soft-typed because each changes at runtime, a class of one kind changes into another - its type changes.
You might keep fundamental and derived non-object types as static though. But this introduces a weird disparity, objects are soft-typed, non-objects are static-typed, and a hard barier must be established between the two. Should you be able to morph a structure? A String? Should Number be a class or a fundamental type, or a set of fundamental types, int/float/bignum/etc?
It is just more natural and easy to learn, use and write to have this uniform, all types are mutable or no types are mutable at runtime. If you declare only one type (Object) is mutable, you end up with headaches and problems of both worlds.
- easier to implement
- faster / more efficient
- easier to maintain/document big systems due to abstraction.
- faster to write in,
- more concise
- language easier to learn
- more forgiving for design errors.
By blending the two, you sacrifice a lot.
- Implementation becomes harder than any of the previous two.
- speed depends if you use the soft types or not... If you do, it's low, if you don't, why pick the language at all?
- type safety is out the window for all object types.
- following how one type morphs into another is a pretty difficult task. Documenting it - very hard.
- You still need to do all the bookkeeping with fundamental types, which kills conciseness and writing speed
- The language complexity is higher (more difficult to learn) than any of the "specific" ones,
- "forgiving" of a dynamic-typed is replaced by tendency to some very tricky errors at mismatching attribute types.