It's important to be aware this says more about you and your personal preferences (and possibly experience and skill in either language) than about octave and its overall value-proposition as a project though.
If I'm allowed to offer a (non-opinionated) counterpoint, I have almost the opposite experience and opinions to you (both in the positives and negatives).
Background: I have been working daily with python for the last 3 years in a scientific field. Before this, I worked daily with octave for about 3 years in a similar field. I'm equally happy and skilled in both languages.
So, to counter:
point 1: I mostly agree, though I think the 'frequent source of bugs' point is slightly dramatic. If anything, to me it feels like the numpy system is much more conducive to bugs (e.g. given all the acrobatics one needs to do to ensure compatible ranks).
point 2: You absolutely do need to import libraries in octave. And that is generally a positive thing for a number of reasons, not too dissimilar to python. However unlike python, the octave team maintains relatively strict control and quality-processes for 'official' and 'endorsed (third party)' packages. This has an advantage over python where for each popular package there are 100 clones and variants and poor or unfinished packages, sometimes even phishing packages.
As for 'packages' in matlab, it's true you don't need to 'import' toolboxes, but this is only because of matlab's business model which sells them as add-ons. You can think of 'enable in licence' as an import of sorts if you'd like.
point 3: Octave derives its plotting syntax from matlab, and for the most part it's very intuitive. I always felt matplotlib is a poor attempt at replicating that syntax, but thankfully there are alternatives.
point 4: It's true that octave's biggest compatibility problem with matlab is in the 'toolboxes vs equivalent package' case. Which is partly why octave has been providing bindings to equivalent python packages as a workaround (same as Julia). One of the more successful examples is octave's reimplementation of python's sympy package, to create a symbolic package using matlab's api and simplicity of syntax, but calling python's sympy under the hood.
As for the "python has more stuff", this is purely the networking effect. And while obvioulsly the networking effect is not a trivial issue for any language, as an open source project it is always a matter of time, which is not something that can be said for something like matlab. And I'm sure that octave's rising popularity in recent years through its promotion in things like Andrew Ng's introductory course to machine learning, can only lead to an increased engagement with the language, and we can expect lots of good packages to crop up as a result.
point 5 (not labelled as such). I don't think the "python > matlab/octave" mantra is necessarily true. It's just personal opinion + engagement. It is certainly true that python has more users, but there are many reasons for that which cannot be reduced to a simple "python > matlab/octave". As for jupyter notebooks, I really dislike them and much prefer matlab/octave's 'publish' for producing straightforward html reports. But, again, that's just personal preference. Also, I much prefer 1-bassed indexing and closed ranges, as I find them much less prone to bugs.
I agree about the prohibitive nature of Matlab's licence, but I do not necessarily agree that the "natural" choice is therefore python. Surely the decision is more multifactorial than that. After all, if it's ecosystem you're after, why not julia? or c++? or java? In my view, octave is a reasonable contender regardless of an existing matlab codebase. It is a friendly language, with a big open-source community, excellent math and graphing facilities, and can easily interface with other languages if you really need that extra pizzaz on occasion, without the overhead that comes from needing to have your whole project based on those languages.