1.  array[0] is syntactic sugar for *(array+0).  0 is an offset from an address, not an index.  
        Lua has tables.  Tables have indexes.  Indexes start at 1.
    2.  a design goal was to be easy for new users, not just existing programmers.  
        begin/end was borrowed from SQL.
    3.  Less operators is less to learn.  New users are familiar with +, -, *, /.  Operators like ++, --, *=, 
        increase the learning curve.  x = x + 1 is not hard to grasp.
    4.  No bitwise operators because no integers.  numbers are 
        floats.
    5.  continue statement is not necessary, adds more
        complexity.  
    6.  Why should it be '!=' and not '<>'

  Indexes start at 1.

2, 3.

Using "it's easier for new users" is not a good argument for a good programming language.

  x = x + 1 is not hard to grasp.

4. Javascript has bitwise operators even though it only has doubles. It simply casts it to an int32 before doing the operation

5.

Continue is very much necessary in loops like this, unless you want some deeply nested code:

    for(...){
    	if(...) continue;
	if(...) continue;
    	if(...) continue;
    	if(...) continue;
    	if(...) continue;
    	
    	...
    }

--

Garry Newman blogged a bit about this too. His game used Lua extensively, but he changed his opinion about it: https://garry.tv/2014/08/16/i-fell-out-of-love-with-lua/.

Now, I don't like JavaScript, but at the moment, it's the best scripting language for embedding out there. I have embedded both lua and v8, and I consider v8 simpler in terms of getting it to work with your code.

It's not my opinion. In any area other than programming, the term index has a specific meaning and indexes start at one. The term used in C for arrays should be called an offset, not an index. It's the wrong word. We called 2^10 a kilobyte too, even though kilo means 10^3.

  for ... do
    if ... then goto continue end
    if ... then goto continue end
    ...
    ::continue::
  end

why the heck not have both? x += y is more elegant than x = x+y. I understand not including ++ (Python) to not enforce 1 as a standard value, but it also doesn't seem to help anyone.

2. Lua's usage of `begin`/`end` was borrowed from "Modula" according to the HOPL paper[1]. Probably Modula-2, but the timeframe would not exclude Modula-3 as a possibility, though I suppose it doesn't really matter.

3. I find this to be a poor argument, but I've never felt like I was missing out on a whole lot by not having modification operators in Lua, either. It's not something that comes up often enough that the couple extra keystrokes should be a deal-breaker.

4. Lua added integers alongside flonums in 5.3, along with bitwise operators, but it's been possible to configure Lua's number representation at compile time for as long as I can remember. Prior to 5.3, anyone with a usecase that really necessitated bitwise operations could easily add them with a dozen lines of C code, or they could use LuaJIT which has offered bitops for some time.

I agree completely with points 5 and 6; nothing to add there :)

[1]: https://www.lua.org/doc/hopl.pdf

Also the barebones standard library wouldn't be much of an issue if there would exist a stable ecosystem, LuaRocks is one attempt but fragile at best.