Two billion features, plus or minus (2^31-2 legal rowid values). I've only loaded 80m personally, but a colleague used my tools to load 680m in Oracle, SQL-Server, and PostgreSQL servers, side by side. That said, the effective useful limit is a lot closer to 20-50 million features.
Tables loaded over time are extremely vulnerable to the effects of spatial fragmentation, which will destroy spatial-first query performance in tables over 2 million rows. If you plan to let the table grow unbounded, you'll need to implement a mitigation plan.
There are an infinite number of permutations of database product, geometry storage, versioning status, and insert behavior which could limit row count -- 2^31-7 versioned edits of an SDEBINARY layer would limit the business table to 5 rows.
For your use case of simple feature insert, the limit is "two gigafeatures". Once you start moving features, then you run into a different limit -- "the total number of features a layer has ever held since the last TRUNCATE" (which is also two gigafeatures). This is probably why "the limit" is not documented.