REF: use iloc instead of _ixs outside of indexing code
Readers are much more likely to be familiar with iloc than _ixs.

This leaves us with exactly one usage of _ixs.
> `_ixs` is considerably faster though (3-4x based on a quick test), so we should maybe not blindly change the one in the other

does this actually matter? more idiomatic code is *much* more preferred I'd say it depends on the performance impact for real-world use cases, balanced against the cost of maintain each. I'm fine with having & using private indexing methods that are can use information known in the calling context to take dedicated paths, which isn't an option in general methods like `.iloc`. > balanced against the cost of maintain each

I've been doing indexing stuff almost exclusively for weeks and still have to double-check what some of the internal methods do.

> depends on the performance impact

Side-note: we can optimize iloc a bit skipping some of the validation and letting numpy's exceptions bubble up.  Thoughts? Performance matters. So unless it is shown that this has no significant impact on an actual use case, I would not just replace it. 
IMHO, `_ixs` is a rather simple, easy to understand function that provides a fastpath to get a single positional column or row. If it is not directly clear what it is doing from the name when reading the code (the name certainly isn't clear), then let's rename it?

> we can optimize iloc a bit skipping some of the validation and letting numpy's exceptions bubble up. Thoughts?

It's certainly useful to optimize iloc I think, but then I would do it as a precursor (or in this PR)
 @jorisvandenbossche can you share how you got to those benchmarks? I think would be helpful to frame discussion I just compared `.iloc[:, i]` with `._ixs(i, axis=1)` on a dummy dataframe.  ive got some optimizations for iloc in the pipeline, will revisit after those.  closing.