Sure, they're "similar", but at a relatively low approximation. The capabilities of the Smalltalk environments are simply on a different plane.

Manipulating the objects and meta/prototype objects are features that both languages allow.

This is sort of a bare minimum for all OO languages. Even Java with its rigidity allows for complex tricks with reflection and method body replacements for hot code reloading.

While this is often considered to be one of JavaScript's weaknesses, the prototypal inheritance model is in fact more powerful than the class based model. It is, for example, fairly trivial to build a class based model on top of a prototypal model, while the other way around is a far more difficult task.

> The capabilities of the Smalltalk environments are simply on a different plane.

Please explain. Maybe use the following examples: FirefoxOS and Squeak

This is precisely what Kay is arguing against in his second point. In Smalltalk everything is an object including classes but there is a sharp distinction between a class and other objects and it's very important to make this distinction. It's important to be explicit about which level you are operating on.

In general arguments about one thing being better than another because you can express one in terms of another don't hold up. Then you can argue that assembly is the most powerful of all. (see also the definition of Turing Tar Pit)

not in languages where you can control method dispatch and object allocation (smalltalk, ruby, python etc), than it's quite trivial.

Some relevant excerpts:

   Here are some examples of conventional operating system
   components that have been naturally incorporated into
   the Smalltalk language:

   [...]

   Display handling -- The display is simply an instance of
   class Form, which is continually visible, and the 
   graphical manipulation messages defined in that class are
   used to change the visible image.

   [...]

   Debugger -- The state of the Smalltalk processor is
   accessible as an instance of class Process that owns a
   chain of stack frames. The debugger is just a Smalltalk
   subsystem that has access to manipulate the state of a
   suspended process. It should be noted that nearly the
   only run-time error that can occur in Smalltalk is for
   a message not to be recognized by its receiver.

   Smalltalk has no "operation system" as such. The 
   necessary primitive operations, such as reading a page
   from the disk, are incorporated as primitive methods in
   response to otherwise normal Smalltalk messages.