A few reasons:
- 99% of custom nodes can’t be just converted to out of the box nodes.
- Many custom nodes actually don’t scale to fully supported nodes as they fail in testing or require a 3rd party toolset which we (Autodesk) cannot reproduce
- Out of the box nodes don’t scale backwards, only forwards. This means that once the OOTB node is implemented the custom nodes would need to be replaced on a version by version instance; my intuition tells me this would be more pain for end users in order to lighten the load on package authors.
- It is possible for package authors to perform a pull request to Dynamo or Dynamo for Revit (which is most of what we are talking about, as there are very few specialized packages for other integrations), which enables the workflow which you’re discussing now. Most aren’t doing so as generally speaking we (the community) aren’t technically ready to do so (only 3 of the top 10 packages meet the initial technical requirements for the base framework, and many nodes thereof are missing required features like icons and documentation).
- The coding standards for getting into Dynamo Core or Dynamo for Revit aren’t clearly documented anywhere. This includes stuff like: how to add icons; when a method should be public vs private vs hidden in the Dynamo library; help documentation requirements; localization requirements; etc… As such it even those who want to contribute cannot (I’m the problem it’s me) without multiple go-arounds with the Dynamo team.
All of this said, the team does try to pick up common needs and integrate them into core; there are a few instances of this in Rhythm and Archi-Lab over the years. Those efforts include python conversions - the FamilyType.ByGeometry node which was based on the FamilyInstance.ByGeometry node as one such example. Unfortunately a lot of the Dynamo team’s efforts in the last 2 years or so have been on required framework stuff (security things, the .net upgrade, geometry engine updates to keep pace with host applications, the visual refresh, etc.) which has limited their capacity to pick up such items.
As far as safety goes: the general responsibility for safety is on end users; always has been and will continue to be. However as stewards of the community and the software therein, we want to ensure the ecosystem is reasonably safe. Think of this as providing crosswalks to help with safe street crossings, package manager needs to own that framework in a way which doesn’t limit street crossings to once every 50 km, while simultaneously not allowing anything to cross at any point.