This is the best feedback so far.

How about this for an abbridged version?

"You can add methods to any objects (no metaclass required), and any object can be inherited form, becoming the prototype of its descendants. In other words, any object can perform the job of a class in a class-based language."

TL;DR: long winded bad analogy, but maybe helpful

That doesn't sound quite right to me. Not that it is wrong, but maybe looking at it the wrong way?

For the discussion, I propose an object has some state, and can receive messages and send messages in response.

A class is the abstract idea of what an object should be like. To break out the bad analogies, it's like ordering from a restaurant menu. You ask the runtime for an instance of a class. If you want something special, you have to have it put on the menu first. Prototype restaurants have no menus, but they have the dishes on display, and you can order those. Or, if you're so inclined, just point at your neighbours' food and order what that guy's having. If he's eaten half of it already, you'll only get as much as he has left, but luckily you can add combine it with other dishes or ingredients as you go.

You can see that if we put some rules in place about which objects can be copied, and what happens during copying exactly, and we call some special objects classes, and use them to create other special objects we call instances, a prototype-based object system can be made to behave like any class-based object system. If we bake those special rules into the language, we make the computer's job easier with hard-wired shortcuts.

How about this:

"In a class based model, skeletal templates (classes) serve as object factories, with something general (the class) serving as the starting point of something specific (an object).

In a prototype based model, the prototype object provides a fully fleshed out starting point for other objects, with something specific (the prototype) serving as the starting point of something even more specific (the inheriting object)"

It felt like the author was using the post as a cathartic persuasion for why prototypes differ from classes. JavaScript functions are a prototype of a class. Prototyping in JavaScript is an analog to class extensions, with elaborate definitions for private/protected variables. It's a debate over semantics and syntax, and it's useless because the analog to a object oriented class can be done with JavaScript's syntax.

  function MyClass()
  {
  	var self = this;
  	var privateVar = 0;
  	this.getPrivate = function() { return privateVar; }
  	this.setPrivate = function(val) { privateVar = parseInt(val); // restrict type }
  	this.publicVar = "Hello World";
  }

  MyClass.prototype.extension = function() {
  	// Here 'this.publicVar' can be set but 'this.privateVar'
   	// and 'privateVar' are not a valid references.
  }

Long story short, the class analog is semantically no different than the JavaScript prototype when done correctly.

Encapsulating instance state us not the point, encapsulating the class behaviour is the point. So, if you can make the prototype itself private and modify the prototype with class methods, you have something that prototypes by themselves do not express.

The analogy is not to a private instance variable in Ruby, the analogy is to a class method in Ruby Dutch as define_method.

I've read it twice and still can't find the point.