Everyone has their own story around this. For me, the reason I did not go with Octave when I chose to migrate from Matlab to Python was that I wanted to be part of a general-purpose language community. Octave had the nice advantage of being very close to the Matlab syntax --- which has some nice properties (e.g. easier matrix-math expressions and matrix-building expressions)

However, I felt there would be more innovation around the programming language itself (think decorators, generators, futures, compilers, and coroutines). The boundary region between "applied-math-programming" and general purpose computing requires a lot of sometimes tedious work. Having a general purpose computing language would mean that more people would be available for that work.

Even now, one of the principal challenges of NumPy which is the foundation of the Python scientific stack is that it combines applied math (fft, linear algebra, polynomials) with computer-science (type systems, data-structures, and multiple-dispatch functionals). Maintaining all of that with one group of people is difficult.

If we could re-factor the NumPy code base into 1) a data-declaration type system --- i.e. look at datashape.pydata.org which is a generalization of dtype, 2) a multiple-dispatch generic function system (the ufuncs) and then 3) a container object. These could all be maintained by separate groups (and even #1 and #2 could be pulled into the Python language itself). See the libdynd project for a reference example of what it could look like.

Then NumPy could be maintained as a set of math libraries on top of that.

Then, it would be relatively straightforward to build the octave DSL on top of the Python computing stack and we would be able to share work.