I'd again look at the intersection of MAP! and OBJECT! and where each apply.
I'd contend that if Rebol 2 had a MAP! datatype from the outset, objects wouldn't be as prevalent as they are and we'd have been better off from having that distinction in code, e.g.:
read/custom http://some.site/ #(
Accept: "text/x-rebol"
)
(continued objections with the #() notation aside, etc.)
Having MAP! values (especially where they have literal notation) takes pressure off that usage of OBJECT! Indeed having MAP! and MODULE! around should already have sharpened the focus for the role OBJECT! fills: not as an awkward stand-in for a key-value type, nor a discrete context for library/support code.
I could refer to the Ten Steps definition where it kind of pertains to classical Object Oriented programming—where that might be desirable (could argue it has its place); or perhaps Javascript where (with but a few exceptions) every value is an object (even Array is but an object with numeric string keys for entries). While I wouldn't necessarily suggest going to the latter extreme, it's not without its own merits (again, is an inspiration for my class proposal).
I don't think any particular idea should be off the table and I don't think it need interfere with any codebases (such that they exist) in that they should for the most part be migrating to MAP! and MODULE! for most all of the common usages
I'd add that it's reasonably clear that JSON 'objects' are analogous to MAP! values and that JSON should map fully to BLANK!, LOGIC!, INTEGER!, DECIMAL!, TEXT!, BLOCK!, MAP! and that OBJECT! be as far away from that discussion as is possible (as it should be from Re[*] source notation).
Back to Javascript, where in addition to stating above that objects are just associative arrays with an inheritance chain and without context, a Map is an Object that acts as a mediator to an additional structure storing keys and values—not effectively different than, say, using an OBJECT! in Rebol 2 to create a map-like interface (except that that structure may be optimized in native code). Could argue that they've tied their own hands by using {...} as Object notation instead of Map