What are the risks of providing SSLv2 for additional device compatibility?

SSL 2 was deprecated in 2011

It was not deprecated, it was outright prohibited which is a huge difference. See also What's the difference between SSLv3 being deprecated and SSLv2 being prohibited?

However many devices are manufactured before 2011 and still in use today

TLS 1.0 was defined 1999 and was available in major TLS stacks (including openssl) from around this time. Not supporting it was already not an option in 2011.

if a well-designed network service provides SSL 2 compatibility

It is a kind of contradictory statement: well-designed vs. providing SSLv2 compatibility. Having a SSLv2 device on the network is not only insecure because of the SSLv2 protocol itself but also because it is highly likely that any old devices which cannot speak any better than SSLv2 wants to use weak ciphers too.

if SSL 2 is not provided, the service will be completely inaccessible a major portion of devices (30~40%) that are otherwise perfectly functional.

Depending on the environment you might be able to secure such devices by adding some software in front so that they are available with better protocols and ciphers.

An example would be a corporate email server for daily communications.

If this server supports only SSLv2 than it must be that old that it has lots of other vulnerabilities. TLS 1.0 was available with Windows XP already.

What exactly are the risks of accepting SSL 2 connections on the server?

While it is bad to have SSLv2 only it is bad to have SSLv2 additionally to other protocols. See DROWN attack for details on how availability of SSLv2 can aid in decrypting properly encrypted connections.

In summary:
if all of this is done within some restricted network where you have no malicious activity the using SSLv2 is probably perfectly safe as would be plain text. But as soon as you have the possibility that someone attacks the network you need to deal with the problems caused by the insecure SSL version (DROWN) and age of SSL stack (weak ciphers) and also at the general software problems (i.e. outdated and probably vulnerable software).

How insecure would it be, today, if a well-designed network service provides SSL 2 compatibility?

extremly insecure, as mentioned by others. If data is really of no importance as you claim, and you absolutely have to support those obsolete devices, you'd be much better to allow only secure TLS connections with 60% of your up-to-date clients, and use plaintext connection for other 40% which would be insecure anyway.

That way when connections are compromised, you'll only have 40% of the damage to cleanup... Additional bonuses is there'll be much better initative to upgrade old devices as people won't (wrongly) think that there is "at least some security with SSL2" (there isn't).

The area that all the other answers seem to be missing is that the relative security (or lack thereof) of using SSLv2 in practical terms depends on the the threat model of the environment that they will be used in.

So everyone would agree that SSLv2 is a weak protocol (more technical details from the inimitable Mr Leek here. Basically an attacker with MITM is going to have more joy at attacking a connection made with SSLv2 and also where it uses weaker ciphers an attacker who can see traffic in a connection might be able to decrypt it more easily. In either case it's fair to say that this still isn't a low-end attack, MITM attacks on SSL aren't trivial to execute and decrypting even relatively weak ciphers takes a bit of effort. Well within nation state attack levels but not generally in the realm of casual or low-end attackers

In addition to this we have DROWN, but the key point about that is, it only applies where another server uses the same private key as the one running SSLv2.

So where does that leave us, back with your threat model. Who are the attackers who might want to compromise your system?

If we're looking at either high-end professionals or nation state, it's fair to say that SSLv2 should not be on the cards in any way, as the weaknesses it has are likely to be exploitable by those attackers

However, if your concerns are more around casual or low-end attackers easily getting access to the data in transit (perhaps it's being transmitted over a wireless network which has other users), then realistically I don't think you're likely to get compromised via an attack on SSLv2

Likely the largest practical business risk in those scenarios is that from a compliance standpoint this won't look good, and also if you get a security consultant in they will flag this up as a risk...

Outwith your SSLv2 problem, from a real-world seurity perspective, I'd likely be far more concerned about likely vulnerabilities in the software operating on these devices, given that it sounds like you won't be able to get security patches for them...