We brought [Serializable] and BinaryFormatter back for .NET Core 2.0 in the name of compat and helping code to migrate to core. But it comes with some serious implications, and it's becoming clear we took things too far. Doing this makes it very easy for code to take dependencies on private implementation details and will end up binding our hands for improvements/optimizations/refactorings/etc. in the future. And with all of the improvements/optimizations/refactorings/etc. already made in core, we've had to punt on the idea of cross-runtime serialization support. There needs to be a better happy-medium.

The primary need for BinaryFormatter and [Serializable] is on a few core types, e.g. primitives, some of the core collections (e.g. List<T>), some small wrapper types (e.g. Tuple), etc. Proposal from me and @morganbr for .NET Core 2.0:

1. BinaryFormatter and friends are currently implemented in System.Runtime.Serialization.Formatters.dll. We keep that as-is.
2. SerializableAttribute, ISerializable, etc. are all implemented in System.Private.CoreLib.dll and exposed through System.Runtime.dll. We keep that as-is.
3. We remove most of the [Serializable] implementations we added back for .NET Core 2.0, keeping the most core and important 10% or so. For this set, we a) potentially implement ISerializable if not already implemented in order to separate the implementation from the surfaced serialization state and to minimize the impact of future refactorings and optimizations, and b) try to enable desktop/core serialization/deserialization, so that BinaryFormatter'd state can go back and forth between desktop and core. We'll need to finalize what the list of types is, but it would include all of the primiteves (e.g. Int32), core collection types (e.g. Dictionary), core wrapper types (e.g. KeyValuePair), Exception and important Exception-derived types, and a handful of others. We can add more types in the future as they're highlighted as blockers, but in the meantime we avoid taking on the burden of lots of serializable types that'll hamper our ability to move the platform forward as we'd like.

[edit]
list of types we ended up scaling back to is here: https://docs.microsoft.com/en-us/dotnet/standard/serialization/binary-serialization#binary-serialization-in-net-core