When you say "returning the data to Python", this probably implies you already have the GIL?

In other words, would there be situations where it might be better just to return the vec structure to Python (as a list) and then take care of wrapping the list as a numpy array from within Python directly?

I think this really depends, but that said, it depends only in the same way as if you would implement that function in say pure Python. So if the return value should conceptually be a list and its only some callers which decide to treat it as an array for their purposes, so be it. If having a Vec is only an implementation detail that should not be visible to the caller, do not expose this and turn it into an array.

That said, turning a Vec into a Python list does have a cost, especially for something like Vec<f64> where the corresponding Python data structure might end up boxing the individual elements. The conversion from Vec<f64> to PyArray1<f64> is also not free, but it has a constant cost unrelated to the number of elements, so especially for large collections this should be more efficient.

Are there any drawbacks to calling Python from rust (complexity, performance, portability, etc)?

As an aside, note that your code snippet does not really call "into Python". Python::with_gil is implemented in PyO3 and manages how Rust code uses the GIL. into_pyarray is implemented in rust-numpy and interacts with NumPy's native code to set up a single Python object holding the Vec so that an ndarray pointing into the Vec can be created with that first object as its base. So there is really very little actual Python code involved.

As a general remark, I would say that calling Python functions does always have a significant cost compared to calling a Rust function just because the calling convention is much more flexible and involved. But I think portability is not a concern if you were called from Python in the first place and want to "call back".

As for complexity, there will also often be a cost due to marshalling arguments and return values as well as having a GIL token at hand, but PyO3 tries to make it as simple as possible. In my personal, experience calling back into Python code is not necessary very often, but when it was, that part of it was obvious. For example, because I wanted to make some part of a larger algorithm open to modification via the Python caller passing in a function which my code would call. But a lot of PyO3-written extensions end up converting their Python-passed arguments into "Rust-native" data structures, process them completely from within the Rust ecosystem and only convert the final results back into Python data structures.