The main reason to do this is that it's unsupported. It's broken in a few different ways (https://github.com/dagster-io/dagster/issues/3577), and we don't have plans to fix it or to make sure it keeps working if we were to fix it. This communicates immaturity and wastes users' time.
I think the content is overall quite quite good, but if we do want to keep it around, here are the things that I think we'd need to do to make it an example I'd feel confident about pointing people to:
* Fix the issues referenced above.
* Use Python type annotations instead of `make_python_type_usable_as_dagster_type` etc.
* Anchor it in some description of what it's trying to accomplish. Is the goal to build some report that people would reference regularly? An ad-hoc data analysis that can be re-run manually when new facts come to light? Feed an application?
* Deal with the commented-out materialization_strategy_output_types in sql_solid.
* It uses solids in places where I think regular Python functions would be wiser, for example in [s3_to_dw_table](https://github.com/dagster-io/dagster/blob/ed8f5a86c923ba748618e0a73e7bea0d4544ae54/examples/airline_demo/airline_demo/solids.py#L300) and [s3_to_df](https://github.com/dagster-io/dagster/blob/ed8f5a86c923ba748618e0a73e7bea0d4544ae54/examples/airline_demo/airline_demo/solids.py#L282). These incur unnecessary materializations and step startup overheads.