This can be worked around by allowing deletion of openssl-devel:
dnf update --allowerasing --best

openssl-devel doesn't seem to be missed by any other packages, and the update concludes succesfully

This is on purpose and will not be changed. Everything should move to openssl-1.1.x sooner or later.

OK, but the essence of this bug is that openssl-1.1 blocks the upgrades for large number of packages that still depend on openssl-1.0, and the only way forward is to delete openssl-1.1 from the system, which seems counterproductive to our stated goal.

Up to now it was possible to have both openssl (1.1) and compat-openssl10 co-installed. Is the newly emerged incompatibility inevitable for technical reasons, or a packaging artifact that could be reverted?

The current situation where the upgrade is blocked is not very good. Teaching people to blindly use --allowerasing is a bad idea: in the past packaging errors led to rampant conflict erasing and unbootable systems: https://bugzilla.redhat.com/show_bug.cgi?id=1601724

оpenssl-devel and compat-openssl10-devel packages always conflicted.

openssl-libs and compat-openssl10 do not conflict - if they do for some reason for you, it is a bug. But I do not see such conflict here.

I had both -devel packages installed previously and they apparently started to conflict very recently. The non-devel packages indeed do not conflict, as you say.

Normally I have -devel packages installed either because they were pulled in as dependencies, or because I was compiling something else that required their .h files or something like that.
I don't remember which one was the case here, but please note that 1040 packages require openssl-devel and 265 packages require compat-openssl10-devel as reported by "dnf repoquery --whatrequires xxxxxx". I believe that most of those dependencies are specified as 'one or another' which is why this situation can be resolved by allowing erase of openssl-devel.

I am sorry, but you must misremember this. The compat-openssl10-devel and openssl-devel packages always explicitly conflicted.
See this commit:

https://src.fedoraproject.org/rpms/compat-openssl10/c/b1a99fb4d28b966757258b18262746573c3d55cd?branch=master

This commit introduced the compat-openssl10-devel package and as you can see there is Conflicts: openssl-devel already.

Basically non-conflicting openssl-devel and compat-openssl10-devel packages would require changes in build process of applications linking to one of these and it would encourage situation where both openssl libraries are loaded into a single process which is in general unsupported although it works OK in many cases. But there are cases where this is completely broken.

Back in July I had openssl-devel for sure
Jul 08 17:44:31 ... upgrade[1260]: [1704/4637] (31%) installing openssl-devel-1.0.1k-10.fc22...
As you say, I almost certainly did not have compat-openssl10-devel then.

I think what happened is that the openssl devel requires specify both openssl-devel and compat-openssl10-devel, and in the past they were satisfied by the openssl-devel package; e.g. 

dnf repoquery  --deplist libssh2-devel-1.8.0-5.fc27.x86_64

dependency: pkgconfig(libssl)
   provider: compat-openssl10-devel-1:1.0.2o-1.fc27.i686
   provider: compat-openssl10-devel-1:1.0.2o-1.fc27.x86_64
   provider: openssl-devel-1:1.1.0h-3.fc27.i686
   provider: openssl-devel-1:1.1.0h-3.fc27.x86_64

Now, maybe recently some packages started requiring specifically compat-openssl10-devel, e.g. 

dnf repoquery  --deplist nodejs-devel

dependency: compat-openssl10-devel(x86-64)
   provider: compat-openssl10-devel-1:1.0.2o-1.fc27.x86_64

causing the conflict.

Ah yes, I was talking about time since upgrade of openssl to 1.1.0 version which happened quite long ago in Fedora 26.

I am sorry, you will have to cope somehow with that. Either remove openssl-devel prior to upgrading or use the allowerasing option.