From the log:

No subtype value/code found for the field 'subtypecd' in table/feature class 'PriOHElectricLineSegment'. Using the default code of '1'

Does that have anything to do with it? 

I also found this topic when googling "2147221230 fme". Do you read from another GDB? Something from source might be interfering?

Thanks for the feedback @nielsgerrits.

I don't think that is the problem. I think all that is indicating is that I am not populating the subtype field form the source data: therefore, it is populating the subtype with the default value from the target (I have a lot more work to do on this and will be adding more and more input fields over time--subtype is on the list at some point). To test this I placed the only target feature class in a fgdb alone and was able to write to it without any problem. So, I am thinking that it must be other objects in the original fgdb that are causing the problem.

To populate the target fgdb with data I am copying a feature dataset that contains a geometric network from sde. This copy operation grabs everything in the feature dataset as well as a number of objects outside it that have relationships to objects within the dataset. Then I am deleting the network and trying to write with FME. Later we plan on recreating the network. Could the relationship classes be causing a problem?

One of the replies in the email suggests problems when writing relations using a basic license.

...a common problem when writing to a Geodatabase, is that FME tries to write into a Geodatabase with Relationships with an ArcView license.
Try forcing FME to use an ArcEditor / ArcInfo - Licence if this is the case or use another geodatabase. 

Hard to say if this is your issue but it's a good habit to exclude problems other people found with the same symptoms.

Working with relations seem to require a Standard or Advanced license, according to the documentation.

This topic also points to license related problems.

I found -2147221230 documented as "E_GSE_BAD_DISTANCE_VALUE" / "Bad distance value in parcel."

Nice find! I was unable to find it on the esri page I was looking at. Thanks!

...a common problem when writing to a Geodatabase, is that FME tries to write into a Geodatabase with Relationships with an ArcView license.
Try forcing FME to use an ArcEditor / ArcInfo - Licence if this is the case or use another geodatabase. 

Good to know. Looks like it is checking out the advanced license on its own. But I did find this article on forcing the license level if needed.

https://knowledge.safe.com/articles/31613/setting-different-license-levels-for-arcgis-and-fm.html

...a common problem when writing to a Geodatabase, is that FME tries to write into a Geodatabase with Relationships with an ArcView license.
Try forcing FME to use an ArcEditor / ArcInfo - Licence if this is the case or use another geodatabase. 

I was able to identify a problem annotation relationship class. Deleting the relationship class in the target fgdb solved the problem. The target feature class has about 8 relationships. A number of them are annotation. So, I am not sure yet why this one is tripping up FME....

I always have a hard time finding ESRI's errorcodes and often give up looking if Google does not return anything useful. Like most things, if you know where to look...

So nothing to do with "Bad distance value in parcel." ? If you can create a test set (sample of input, workspace, target gdb) it is easier to reproduce and look.