Are there any reasons opinion 1) would be preferred to opinion 2) other than speeding up development and reusing code.
Option 1 is just because of pure laziness and imagined increased development speed. It’s true that those applications will get version 1.0 built faster. But when those developers reach version 3.0 of the application, they do not think it’s so fun to maintain the application due to all compromises that they have had to do in the domain model due to the ORM mapper.
Are there any issues in my approach of mapping the models? Is there something I missed that would bring up issues when a solution grows?
Yes. The repository should be responsible of hiding the persistence mechanism. It’s API should only work with domain entities and not persistence entities.
The repository is responsible of doing conversions to/from domain entities (to be able to persist them). A fetch method typically uses ADO.NET or an ORM like Entity Framework to load the database object/entity. Then convert it to the correct business entity and finally return it.
Otherwise you would force every service to have knowledge about persistence AND working with your domain model, thus having two responsibilities.
If you work with application services per the DDD definition you will probably want to look at the Command/Query separation pattern which can be a replacement of the application services. The code gets cleaner and you also get a much more lightweight API wrapping your domain model.