There are pros and cons to both zero and one based indexing, but in the context of Lua going with 1-based indexing was IMO a complete disaster, and one of maybe two or three significant defects that has relegated an otherwise quite elegant, small and capable language with one world class implementation to some weird niche role.
You just can't succeed in being the goto language for embedding (in C or C++) and have 1 based indexing. It's just a complete clusterfuck and you end up with all sorts of truly terrible things, like luajit or terra being sometimes zero and sometimes one based, which also interacts in hilarious ways with the length function. I think this has done even more harm than the messed up scoping (which could largely be fixed).
I write Lua in my free time so I have a lot of respect for language. Regarding 1-based indexing I don't care one way or another. I often switch back between C, Python, JS and Lua. At first I was bothered by differences and blamed Lua for being more verbose or using unconventional indexing. After a while I can just switch the language mindset and use 1-based indexing where appropriate.
I agree about the scoping though, it should default to local.
I think what most people really want is to avoid implicit scoping altogether. But then you need a special keyword to access global environment symbols. That's a little awkward in Lua because the "require" function used to import libraries is just a regular function in the global environment table (which is otherwise just a plain table), and so `local string = require"string"` works because undeclared symbols become an index into the global environment table. And libraries like "string", "math", etc are also usually prepopulated.
A lot of people do `require"strict"` (or if you want to be pedantic, `local _ENV = require"strict"`) early in a Lua source file, which modifies the global environment to throw a runtime error instead of returning `nil` for undefined symbol lookups. (There are various versions of the strict library floating around; it doesn't come with stock Lua.) If would be better if this was a static check in the language itself. That, too, isn't a difficult addition (it could even be added to a strict library, or you could overload require), but defaults matter when it comes to nitpicking languages, I guess.
Maybe in Lua 5.5 or 6.0 this change will be made. Though, statically-checked scoping isn't as as straight-forward as you'd think given Lua's common use as a fast-and-loose sandbox for running user code, ad hoc business logic modules, etc, where a lot of preamble boilerplate can seem overly complex. But the upside to Lua having a loose commitment to backward compatibility is that it's much easier to experiment with these sorts of changes and keep iterating until they nail down a solid construct. For example, compare setfenv/getfenv in Lua 5.1 with the lexical _ENV construct in Lua 5.2.
I have no problem switching between 1 and 0 based languages and have used both productively; as I said both have their pros and cons. If lua were mostly some standalone language, or even a glue language to the extend python is, there would not be an issue.
So if you mostly write vanilla Lua, yeah, I agree, 1 based indexing will not affect you much (unless you have some psychological hangup). But vanilla lua is to almost all extents and purposes a vastly inferior value proposition to python. And once you try to do some high performance stuff with luajit or terra or use luajit for embedding/glue purposes, the 1 based indexing will immediately become a point of major and utterly needless friction.
So one based indexing weakens Lua chief differentiator: being small, fast and very pleasant to embed or interface to C or C++ with; luajit in particular is probably without compare in this regard. So that's why it's in my view a chief contributor to Lua's failure (not in some absolute sense, but certainly relative to the engineering brilliance that went into both PUC lua and luajit in particular, especially when compared to languages with amateurish design, implementation or both -- such as early php, ruby or python all of which are vastly more successful).
You just can't succeed in being the goto language for embedding (in C or C++) and have 1 based indexing. It's just a complete clusterfuck and you end up with all sorts of truly terrible things, like luajit or terra being sometimes zero and sometimes one based, which also interacts in hilarious ways with the length function. I think this has done even more harm than the messed up scoping (which could largely be fixed).